Под обновлением данных в БД подразумевается изменение значений в существующих записях таблицы. При этом возможно как изменение значений полей в группе строк (даже всех строк таблицы), так и правка значения поля отдельной строки.
В SQL, изменить запись в таблице БД можно с помощью команды UPDATE. В самом минимальном виде команда обновления данных выглядит следующим образом:
UPDATE таблица SET поле = значение
Здесь, UPDATE – команда указывающая, что запрос на обновление данных;
таблица – название таблицы, в которой будет проводиться изменения;
SET – команда, после которой через запятую указываются поля с назначаемыми им значениями;
поле – поле таблицы, в которое будет внесено изменение;
значение – новое значение, которое будет внесено в поле.
Например, если необходимо задать полю во всех строках таблицы значение равное нулю, можно выполнить такой запрос:
UPDATE goods SET price = 0
В этом случае, поле price абсолютно во всех имеющиеся строках таблицы примет значение 0.
Как сохранить личные файлы и программы при обновлении с Windows 7 до Windows 10, восстановлении 10
Изменение одного значения
Изменение значения всех полей в таблице необходимо крайне редко. Чаще всего необходимо поменять значение какой-то конкретной записи. Для этого в завершении строки с командой UPDATE будет добавлена директива WHERE, в которой указывается условие, определяющее с какой именно строкой нужно выполнить операцию обновления.
| num (номер товара) |
title (название) |
price (цена) |
| 1 | Чайник | 300 |
| 2 | Чашка | 100 |
| 3 | Ложка | 25 |
| 4 | Тарелка | 100 |
Для примера, нужно обновить стоимость товара с известным нам его значением num. Для этого, выполним следующий запрос:
UPDATE goods SET price = 150 WHERE num = 2
Теперь, перед операцией изменения полей, будет выбрана строка, удовлетворяющая условию num = 2. Такая строка в таблице одна. В этой стоке цена и будет изменена на значение 150. В результате получим таблицу с измененной ценой товара.
Внесение изменений в несколько строк с условием отбора
Если вспомнить все многообразие условий в запросе, можно представить себе насколько разнообразными могут быть выборки. Поэтому и запросы на обновления могут выполняться либо с одной строкой, либо с группой строк, либо со всеми строками таблицы. Все зависит от стоящей перед вами задачи, а так же с какими строками таблицы нужно выполнять операции обновления.
Например, мы хотим уменьшить в два раза цену всех товаров, которые сейчас стоят от 100 и более. Запрос:
UPDATE goods SET price = price / 2 WHERE price >= 100
Условие WHERE здесь содержит правило, по которому будут выбраны только товары с ценой равной или более 100, а те товары, цена у которых ниже 100, затронуты запросом не будут.
ЛУЧШАЯ ПРОГРАММА ДЛЯ ОБНОВЛЕНИЯ ДРАЙВЕРОВ
price = price / 2 – формула, по которой будет вычисляться новая цена товаров. Новая цена будет записана равной старой цене поделенной на два.
В результате выполнения такого запроса получим таблицу с измененными записями:
| num (номер товара) |
title (название) |
price (цена) |
| 1 | Чайник | 150 |
| 2 | Чашка | 50 |
| 3 | Ложка | 25 |
| 4 | Тарелка | 50 |
Обновление значений в нескольких полях строки
При необходимости обновлять сразу несколько полей, все поля с их значениями указываются после директивы SET через запятую. Например, нужно изменить название и цену товара с кодом 2 на «утюг», стоимостью 300:
UPDATE goods SET title = «утюг», price = 300 WHERE num = 2
Такой запрос каждому соответствующему полю в строке назначит его значение. А условие укажет, в какой именно строке будут выполнены изменения.
Выше приведены основные виды операций обновления. На их основе формируется запросы для решения большинства задач изменения данных в разработке с применением SQL.
Источник: space-base.ru
Пишем свой сервис авто-обновлений
Большинство разработчиков stand-alone приложение рано или поздно сталкиваются с проблемой доставки обновлений для своего приложения. В этой статье я постараюсь решить эту проблему наилучшим, на мой взгляд, способом — написать свой собственный универсальный сервис авто-обновлений, который будет висеть в процессах в единственном экземпляре и доставлять обновления для всех подписавшихся приложений.
Существует несколько готовых решений для .NET, но самое актуальное — это ClickOnce. Эту технологию уже нельзя назвать новой, однако серьёзное развитие, на мой взгляд, она получила не так давно, и не обладает исчерпывающим функционалом.
Если вы не хотите изобретать велосипед, то советую вам пристально изучить возможности ClickOnce, и если вам будет достаточно предлагаемого функционала, то это определенно ваш выбор. Однако ClickOnce не панацея и далеко не всегда ею можно обойтись.
Сейчас же я хочу рассказать о своём видении механизма авто-обновлений. Я не претендую на истинность в последней инстанции, так что конструктивная критика и предложения в комментариях приветствуются.
UPD: Суть реализации заключается в том, чтобы уменьшить количество процессов и служб, которые занимаются обновлением. Если у вас несколько приложений, то все они смогут «получать» обновления от одного единственного Windows-сервиса. Не надо будет для каждого приложения запускать лаунчер, держать соединение с сервером обновлений.
Теоретически в системе всеми обновлениями может заниматься один процесс, и возможно этим процессом скоро станет ClickOnce, если разработчики перестанут делать свои «велосипеды». А разработчики перестанут делать свои велосипеды тогда, когда им будет достаточно функционала ClickOnce. Сейчас, к сожалению, это не всегда так.
Итак задача
Пусть у нас есть несколько разных приложений, установленных на компьютере пользователя. Мне бы хотелось написать универсальный сервис авто-обновлений, чтобы потом я мог использовать его и в других приложениях. И все приложения обновлялись используя только одну службу, что сэкономило бы ресурсы при большом количестве софта. Так же желательно, чтобы в существующих приложениях мне потребовалось внести минимальные изменения для подключения и настройки авто-обновлений. Процесс обновления должен быть настраиваемый для каждого приложения.
Реализация
Чтобы как-то конкретизировать задачу, решать её я буду применительно к ОС Windows, код писать на C#.NET, хотя в этой статье я буду в основном оперировать абстракциями и приводить только небольшие отрывки кода.
Мой сервис авто-обновлений состоит из 3 модулей:
1) Веб-сервис с самими обновлениями, учетом версий, базой данных всех поддерживаемых приложений и всем остальным что можно сюда вынести (например некоторые “удаленные” настройки процесса обновления конкретного приложения).
2) Windows-сервис, который будет коннектиться к веб-сервису и поверять обновления для всех подписанных приложений, по таймеру и по требованию.
3) Client-библиотека, которая будет знать как коннектиться к Windows-сервису Updater’а, а так же предоставлять приложению callback интерфейс.
Я разнес это все на 3 сборки и назвал соответственно.
Updater.Online — веб-сервис
Updater.Service — windows-сервис
Updater.Client — клиентский-модуль
Так же я выделил еще одну сборку для общих абстракций — Updater.Domain.
Updater Online
Начнем с Веб-сервиса. Тут всё просто, все можно впихнуть в один метод CheckForUpdates, который принимает ApplicationID и CurrentVersion, смотрит в базе есть ли актуальные обновления для данного приложения, и если есть возвращает путь к .zip файлу с обновление или null если обновлений нету. Это простейший случай, вообще как и запрашиваемых параметров так и результатов запроса может быть больше.
Сервис может возвращать дополнительную информацию, которая может пригодиться в процессе обновления. Например на сервисе можно указывать возможно ли обновление в silent-mode для данного приложения, дополнительные данные о том как скачать обновление, в каком оно формате, какой у него размер и т.д.
Updater Service
Это пожалуй самый объёмный модуль. Здесь находится WCF сервис UpdaterService, ниже приведен интерфейс, который он реализует, и callback-интерфейс.
[ServiceContract(CallbackContract = typeof(IUpdateServiceCallback))] public interface IUpdaterService < #region Callback subsctibe/unsibscribe methods [OperationContract(IsOneWay = true)] void Subscribe(SubscribeRequest request); [OperationContract(IsOneWay = true)] void Unsubscribe(UnsubscribeRequest request); #endregion [OperationContract(IsOneWay = true)] void InstallAvalibleUpdates(InstallAvalibleUpdatesRequst request); [OperationContract(IsOneWay = true)] void DownloadUpdate(Guid applicationId); [OperationContract(IsOneWay = true)] void CheckForUpdates(Guid applicationId); >[ServiceContract] public interface IUpdateServiceCallback
В методе Subscribe я добавляю callback, который пришел от клиента в статический Dictionary, где TAppID — айдишник приложения ( у меня Guid), для каждого приложения отдельный список callback’ов.
Вот реализация метода Subscribe
public void Subscribe(SubscribeRequest request) < // Достаем из контекста calback переданный клиентом IUpdateServiceCallback callback = OperationContext.Current.GetCallbackChannel(); //делаем lock, чтобы синхронизировать работу с коллекцией приложений lock (sync) < // Получаем от сервиса объект типа Application по его ID. Если такого нету, // то создаём новый. Добавляем/обновляем информацию о подписанном приложении var app = applicationService.Get(request.ApplicationId); if (app == null) < app = new Application() < >; applicationService.Add(app); > app.CurrentVersion = request.Version ?? app.CurrentVersion; app.RootFolderPath = request.RootFolder ?? app.RootFolderPath; app.Name = request.ApplicationName ?? app.Name; > // Получаем лист callback’ов для текущего приложения или создаём новый, // добавляем подписку к делегатам var list = GetEventList(request.ApplicationId) ?? new CallbacksList(); list.OnUpdateDetected += callback.OnUpdateDetected; list.OnUpdateDownloaded += callback.OnUpdateDownloaded; if (registredCallbacks.ContainsKey(request.ApplicationId)) < registredCallbacks[request.ApplicationId] = list; >else < registredCallbacks.Add(request.ApplicationId, list); >// Подписываемся на события объекта связи, чтобы отслеживать // закрытие клиента и выполнять некоторые действия (например // проверять отписался ли он) ICommunicationObject obj = (ICommunicationObject)callback; obj.Closing += ClientClosing; obj.Closed += ClientClosed; applicationService.SaveChanges(); >
Так же в реализации UpdaterService я добавил статические методы для вызова Callback, чтобы немного скрыть саму реализацию их вызова. Эти методы вызваются на стороне Updater Service, когда необходимо инициировать соответствующие события на сторон клиента.
private static Dictionary registredCallbacks; // Метод выбирает из словоря список callback’ов или возвращает null если его там нету private static CallbacksList GetEventList(Guid appId) < CallbacksList result; return registredCallbacks.TryGetValue(appId, out result) ? result : null; >// Предоставляет список callback’ов и выполняет выбранный private static void PerformCallback(Guid applicationId, Action func) < try < var list = GetEventList(applicationId); if (list != null) < func(list); >> catch < >> // Метод инициирует событие OnUpdateDetected на всех подписанных клиентах // с указанным ApplicatioId public static void OnUpdateDetected(UpdateDetectedEventArgs args) < PerformCallback(args.ApplicationId, callbacks =>callbacks.OnUpdateDetected(args)); >
Так же на сервисе я запускаю “таймер”, который проверяет обновления для всех подписанных приложений через заданный промежуток времени.
У меня в коде фигурирует ApplicationService, хоть я и назвал его сервисом, он больше похож на хранилище информации о подписанных приложениях и обновлений для них.
Вот классы приложения и обновления.
public class Application < public Guid Id < get; set; >public String Name < get; set; >public Version CurrentVersion < get; set; >public String RootFolderPath < get; set; >public List Updates < get; set; >> public class Update < public String UpdateUrl < get; set; >public Version Version < get; set; >public bool IsInstalled < get; set; >public bool IsDownloaded < get; set; >public string UpdateLocalPath < get; set; >>
Updater Client
Эта сборка подключаеься в приложении и следит за сообщениями с Updater сервиса, сообщая о них приложению через объект реализующий IUpdateServiceCallback.В качестве callback’а передаваемого сервису можно использовать тот же объект, что был передан из приложения в Updater Client, но лучше сделать обертку, чтобы фильтровать информацию, передаваемую клиентскому приложению, а не пихать ему все подряд, что вернет Updater сервис. В приведенной мной реализации обертка не используеться. Так же клиентское приложение передает данные о себе в виде объекта, реализующего интерфейс IUpdatаble.
public interface IUpdatаble < Guid ApplicationId < get; >String ApplicationName < get; >String RootFolder < get; >> public class UpdaterClient < private IUpdaterService client; private IUpdateble settings; private DuplexChannelFactoryfactory; public UpdaterClient(IUpdateServiceCallback callback, IUpdateble settings) < this.settings = settings; var context = new InstanceContext(callback); var binding = new NetTcpBinding(); // Создаем фабрику двусторонних каналов связи, в качестве колбэка // используем переданный в конструктор пользовательский объект, // который реализует интерфейс IUpdateServiceCallback factory = new DuplexChannelFactory(context, binding, new EndpointAddress(UpdaterSettings.Default.UpdaterServiceUrl)); client = factory.CreateChannel(); > // Предоставляем клиенту методы сервиса, в качестве // параметров используем данный из Iupdateble объекта, // который был передан в конструкторе public void Subscribe() < client.Subscribe(new SubscribeRequest() < ApplicationId = settings.ApplicationId, RootFolder = settings.RootFolder, Version = settings.Version, ApplicationName = settings.ApplicationName >); > public void Unsubscribe() < client.Unsubscribe(new UnsubscribeRequest() < ApplicationId = settings.ApplicationId >); > public void InstallUpdates(bool reopenOnComplete) < InstallUpdates(reopenOnComplete); >public void DownloadUpdate() < client.DownloadUpdate(new DownloadUpdateRequest() < ApplicationId = settings.ApplicationId >); > public void CheckForUpdates() < client.CheckForUpdates(settings.ApplicationId); >public void InstallUpdates(bool reopenOnComplete) < client.InstallAvalibleUpdates(new InstallAvalibleUpdatesRequst() < ApplicationId = settings.ApplicationId, RestartOnComplete = reopenOnComplete >); > >
Ну вот собственно и всё. Используется на стороне клиента следующим образом — подключаем сборку Updater.Client, создаём объект типа UpdaterClient, вызываем метод Subscribe, и наше приложение начинает получать сообщения от сервиса о новых обновлениях.
- .NET
- Проектирование и рефакторинг
- C#
Источник: habr.com
Обновление вспомогательных данных
Вспомогательные данные – это особый вид данных, которыми необходимы для удобства работы пользователей. Они никак не меняют логику работы системы 1С. Управление, в том числе, обновление вспомогательных данных производится при помощи подсистемы «Базовая функциональность».
Для того чтобы обновить вспомогательные данные, первым делом необходимо произвести настройку и проверить подсистему «Базовая функциональность». Эта подсистема вмещает в себя весь первоначальный функционал системы 1С, при этом он является обязательным для каждого из прикладных решений, в которых используется библиотека. Помимо вспомогательных данных, к базовой функциональности относятся функции и процедуры, которые имеют общее назначение, а также перечень с универсальными обработками данных и стандартные роли, такие как «БазовыеПраваБСП», «ПолныеПрава» и так далее.
Рассмотрим, как происходит настройка основных базовых типов. Когда внутри конфигурации имеется справочник «Организация», то нужно в обязательном порядке:
· прописать его ссылку внутри свойства «Тип», который является определяемым типом внутри «Организации»; · сделать реализацию функции по экспорту внутри модуля менеджера для справочника «Организации» в области «ПрограммныйИнтерфейс», как показано на скриншоте кода ниже:
Рис. 1 Функции по экспорту в справочнике Организации
2. Работа и пуск системы
Рассмотрим алгоритм работы и пуска системы перед началом обновления вспомогательных данных. Все действия до начала работы, а также перед окончанием работы должны находится в процедурах для общего модуля «ОбщегоНазначенияКлиентПереопределяемый: ПередНачаломРаботыСистемы, ПриНачалеРаботыСистемы», а также «ПередЗавершениемРаботыСистемы». Также стоит помнить, что в работе модели сервиса информация из процедуры может вызываться не только во время фактического входа или выхода, но и во время интерактивного входа или выхода администратора из базы информации для областей данных.
Чтобы минимизировать вызовы на серверную часть, во время начала работы системы лучше всего прямо вызывать процедуры из сервера, а также функции, которые находятся в коде модуля в приложении и в модуле управляемого приложения. Чтобы осуществить передачу для клиента всех параметров, которые нужны для запуска кода клиента, нужно воспользоваться функцией «ПараметрыРаботыКлиентаПриЗапуске» в общем модуле «СтандартныеПодсистемыКлиентПовтИсп». Когда функция вызывается в первый раз, то обращение к серверу является единственным, после чего значение подлежит кешированию на клиенте для каждого из следующих вызовов вышеописанной функции.
Если есть необходимость передать больше параметров, то добавляем все новые параметры в функцию «ПараметрыРаботыКлиентаПриЗапуске» в общем модуле «ОбщегоНазначенияПереопределяемый».
3. Обновление вспомогательных данных
В некоторых случаях, когда происходит разработка и отладка конфигурации, необходимо сделать обновление по вспомогательным данным, так как они имеют влияние на работу программы, а именно: на служебные регистры сведений, на кеши по свойствам метаданных и так далее.
Чтобы обновить вспомогательные данные следует придерживаться таких пунктов:
1. чтобы обновление вспомогательных данных произошло полностью необходимо использовать внешнюю обработку «ОбновлениеВспомогательныхДанных.epf», она находится в составе дистрибутива в библиотеке;
2. сделать наиболее оптимальное обновление всех вспомогательных данных, для этого нужно прописать параметр запуска «ЗапуститьОбновлениеИнформационнойБазы» внутри самого конфигуратора, либо при помощи параметра на строке с командами «/С»;
3. во время закладки всех перемен, которые могут потребовать обновление вспомогательных данных, в хранилище нужно обновить номер версии конфигурации, тогда у всех остальных участников общей разработки автоматом будут запущены обработчики для обновления. Все случаи для обновления вспомогательных данных всегда помечены в тексте документации на подсистемах, а также имеют приставку «Внимание».
Во всех иных случаях вспомогательные данные обновляются автоматически, во время обновления номера (версии) конфигурации, а именно: когда происходит заполнение базы с информацией.
Специалист компании «Кодерлайн» Анна Лисовая
Источник: www.koderline.ru