Запись параметров
Александр
Родин; 29.11.01
Возникла следующая проблема.
Когда мы сохраняем большой объем данных, это, естественно, занимает
большой промежуток времени. Все бы ничего, но при этом теряется
возможность управления процессом. Т.е., пока выполняется процедура
сохранения, управляющие воздействия к контроллеру не передаются.
Правда, после завершения записи, все кнопки, которые до этого
нажимались, передаются.
Однако, потеря возможности управления в процессе записи является
большой проблемой.
Если кто-то сталкивался с таким поведением, и может что-то
посоветовать, очень бы хотелось пообщаться.
Заранее спасибо.
Re: Запись параметров
Юрий
Оганесян; 30.11.01
Есть стандартный прием: записывать гораздо ЧАЩЕ (соответственно
меньшими кусками), ну а далле:
опитмизация базы данных, использование для неё другого компьютера и
т.д.
Re: Запись параметров
Александр
Родин, ООО "Нева Электрик"; 30.11.01
Пробовал меньшими кусками.
Для полноты картины привожу конкретный пример:
В архиве сохраняется порядка 50 переменных. Цикл опроса 1 секунда,
архив расчитан на сутки.
Таких архивов 2. Одновременно экспорт ведется только из одного из
них. Причем, экспортируются сразу все переменные этого архива (так
надо по заданию). Экспорт не циклический, а по команде оператора с
выбранным фрагментом.
Так вот, если мы выбираем фрагмент 5 минут, экспорт длится порядка
2-х минут, а при выборе фрагмента 2 часа, экспорт длится порядка 4
минут. Причем, перед тем как выполнять экспорт я предварительно
останавливаю архивирование (с помощью TLGLockArchiv). Ладно, пусть
он и длится сколько угодно. Но в это время невозможно управлять, а
это не очень хорошо.
Насчет другой машины я тоже думал. Но заказчик на это не
пойдет.
Вот такая вот незадача.
Заранее спасибо.
Re: Запись параметров
Юрий
Оганесян; 3.12.01
Судя по приведенным Вами цифрам основное время при экспорте уходит
не на саму передачу и конвертирование данных, а на поиск
необходимых данных в архиве. В этом случае надо ускорить именно
поиск.В случае последовательного архива технологических данных
самое лучшее - это КЛАСТЕРНЫЙ индекс по полю времени (дате).
Правда, это мои общие соображения, я это применял при работе с
архивом на MS SQL, а Вы,
как я понял, работате на WinCC. Можно ли там через централь
Sybase'a или как-то еще
внедриться таким образом в связь WinCC-Sybase я не знаю.
В целом, насколько я в курсе, под Windows нет средств увеличения
системного приоритета
законченным приложениям (exe-шникам), так что, по-моему, без
дополнительного компьютера
можно только качественно влиять на описанную ситуацию, но ничего
кардинального
на уровне алгоритмов сделать не удастся, разве что кардинально
пересмотреть весь механизм архивирования.
Посмотрите что можно сделать с железом - например, хранить архив на
отдельном винте
с RAID 0/1, кстати, если хорошо объяснить, что это такое, то
заказчик на это может
даже и согласиться, правда есть очень большой риск самому пролететь
- если от этого
произоводительность не увеличится :)
Re: Запись параметров
Александр
Родин, ООО "Нева Электрик"; 3.12.01
Из WinCC, насколько я знаю есть возможность вызова внешних
приложений.
В принципе, если обеспечить вызов внешней утилиты SQL-евской базы с
ключами для экспорта во внешний файл, то это, по-моему, должно
решить проблему. Правда, возникает ряд вопросов: ждет ли WinCC
флага выполнения внешнего приложения, будет ли работать указанная
утилита (если она такая есть) при запущенном RunTime'е, насколько
такой метод загрузит систему ? Да и вообще, возможно ли найти
описание подобного метода ? Может кто-то так уже делал.
Заранее спасибо.
Re: Запись параметров
Александр
Родин, ООО "Нева Электрик"; 27.12.01
Используемая для экспорта данных функция TLGBackUp очень медленно
выполняет экспорт. Причем на скорость мало влияет и размер
фрагмента, и использование другого железа. Но самое большое
неудобство приносит тот факт, что на момент выполнения этой функции
RunTime перестает воспринимать команды от оператора (нажатие кнопок
и т.д.). Если бы возможно было убрать процесс экспорта в фоновый
режим, было бы просто замечательно (обратите хотя бы внимание на
опыт других SCADA, к примеру Intellution FIX). Правда, есть вариант
выполнения экспорта внешним приложением (утилита isql.exe), но при
этом не сохраняется информация об уже выполненном экспорте, и,
соответсвенно, нет возможности вести историю сохранений. Конечно,
все это можно сделать самому, но тратить на это время, когда на
выполнение достаточно объемного проекта дается от силы месяц, не
очень хочется. Как я успел заметить, что в 4-х, что в 5-х версиях
WinCC проблема эта одна и та же. Могу только одно сказать: обидно,
что из-за какой-то ерунды приходится искать возможности перехода на
другие SCADA. На самом деле, если бы не этот "глобальный"
недостаток, WinCC мне нравится больше.
Может, все-таки, подскажете как можно выполнять экспорт данных при
помощи других системных функций и при этом вести историю сохранений
?
Заранее спасибо.
Re: Запись параметров
Никаноров, Сименс; 27.12.01
Эх.
Дело не в фоновом режиме и не в функции TLGBackUp, а в том, что
загрузка процессора при таких операциях возрастает до 100%.
Вы можете делать экспорт, используя утилиты Sybase (isql.exe,
dbisql.exe). При этом Вы можете точно также как и при использовании
TLGBackUp, вести "историю сохранений". Вызываете из скрипта
isql.exe с нужными параметрами, формируете нужное имя файла или
каталога и т.п. Всего несколько строк кода. Примеры можно
посмотреть в ConfigurationManual, в ComprehensiveSupport (на наших
дисках WinCC) и в CustomerSupport.
Re: На заметку разработчикам
СИМЕНС
Александр
Родин, ООО "Нева Электрик"; 27.12.01
Как вызвать isql с ключами для экспорта я нашел. Как сделать то же
самое для восстановления тоже нашел. Но вот как вести историю
сохранений ?.. В указанных ресурсах этой информации, к сожалению,
нет.
Заранее спасибо.
Re: Запись параметров
Никаноров, Сименс; 27.12.01
А что Вы понимаете под историей сохранений?
И как Вы это делаете в настоящее время?
Вот так ответ!
Юрий
Оганесян; 27.12.01
Вот так ответ: все развернуто наоборот: оказывается, виновата не
функция, загружающая процессор, а сам процессор, который, почему-то
загружается от этой самой функции.
А вообще-то загрузка процессора на 100% - это совершенно нормальная
ситуация, которая возникает практически постоянно при любой, самой
"офисной" работе на компьютере.
Re: Вот так ответ!
Александр
Родин, ООО "Нева Электрик"; 27.12.01
Если бы это можно было считать нормальной ситуацией, я бы не сидел
сейчас здесь с обсуждением этой "ерундовой" проблемки.
Конечного заказчика не устраивает такое поведение системы, на
разработку которой он тратит свои деньги. И чем не мотивируй, лучше
от этого не станет.
Такие дела.
Re: На заметку разработчикам
СИМЕНС
Александр
Родин, ООО "Нева Электрик"; 27.12.01
История сохранения ведется автоматически при использовании функции
TLGBackup. И заносится в таблицу PDE#Backup (кажется так). Потом
всю информацию о выполненных сохранениях (экспортах) можно вытащить
посредством функции TLGBackupEnum.
Собственно, так оно все и делалось. Но это приводило (да и
приводит) к очень большим задержкам даже при попытке восстановить
5-и минутный архив из 50 переменных.
Кстати говоря, при достаточно заполненной RunTime базе, даже при
использовании isql получается чувствительная задержка при выдаче
команд управления. (В архив записываются последние 24 часа, с
дискретностью в 1 секунду, количество переменных - 42; Максимальный
фрагмент для экспорта - 8 часов)
И на самом деле, загрузка процессора при выполнении этого
приложения держится на уровне 100%.
Re: На заметку разработчикам
СИМЕНС
Никаноров, Сименс; 27.12.01
1. Загрузка процессора.
Имелась ввиду загрузка процессора на 100% на длительное время.
Пиковые загрузки до 100% - это действительно нормальная ситуация.
Но длительная загрузка до 100% естественно приводит к затруднению
управления. И дело здесь не в какой-то функции ODK, а в том что
операции типа экспорт-импорт по сути сводятся к поиску в базе и
записи на диск, что и вызывает продолжительную загрузку ЦПУ и
дисковой подсистемы.
Остается только оптимизировать этот процесс. В связи с этим см.
нижеследующий текст.
2. ISQL делает экспорт\импорт несколько быстрее, чем ODK-функции.
Поэтому имеет смысл использовать эту возможность. А "чувствительная
задержка" связана с тем, что в Вашем случае Вы экспортируете
8х3600х42=1209600 записей. Запись занимает в среднем 40 байт. Итого
48384000 байт. Т.е. нужно извлечь из базы и записать на диск
порядка 40Мб. Даже если Вы будете просто копировать 40Мб файл, Вы
почувствуете "задержку управления".
3. История сохранений, если я правильно понял, используется для
последующего восстановления (импорта) данных. Кроме того, импорт
приводит к значительно большим задержкам, чем экспорт. В связи с
этим не очень понятно, зачем вообще нужен импорт, если у Вас
кольцевой архив на 24 часа? Т.е. Вы делаете не экспорт данных, а
свопинг с последующим восстановлением?
Все вышесказанное я хочу подвести к следующему.
- использовать ISQL.exe
- обойтись без импорта, если это возможно
- если все-таки нужен импорт, делать его при помощи опять-же ISQL,
а историю сохранений делать самостоятельно (по сути для импорта
необходимо только имя архива и имя файла)
- также остается возможность модернизации хардвера: два жестких
диска, процессор и т.п.
- использовать опцию Storage, которая все нужные Вам функции делает
автоматически
Re: На заметку разработчикам
СИМЕНС
Александр
Родин, ООО "Нева Электрик"; 27.12.01
Если позволите, несколько замечаний:
1. я читал мануал по TagLogging, и там указан размер для одной
записи порядка 28 байт. Хотя, да... с учетом формата экспорта в
ASCII размер записи приближается к 40 байтам. Но при этом, как не
странно, экспорт в ASCII занимает намного меньше времени и размер
файла для одной переменной(8 часов) не превышает 1 Мб. Пакуются
такие данные в 10-15 раз (например для переноса на дискету).
2. Импорт нужен даже не мне, а заказчику. Мотивация: Не до конца
проработанная система, по которой нужно хранить всю историю работы,
с целью потом поднять заархивированные данные, где-нибудь месячной
давности. С учетом того, что объект находится, например, в Сибири,
а производитель здесь, в Питере, то, естественно, проще получить из
Сибири дискету с трендовыми данными, чем копировать весь проект. В
связи с этим, возможность импорта необходимо предусмотреть.
И вопрос: а можно где-нибудь посмотреть подробную информацию о
функциях Storage?
Заранее спасибо.
Re: На заметку разработчикам
СИМЕНС
Никаноров, Сименс; 27.12.01
С первым пунктом полностью согласен. ПРавда не указано, по
сравнению с чем "экспорт в ASCII занимает намного меньше времени".
Да и размер записи варьируется от 30 до 50 байт.
С импортом опять не все понятно. Если данные нужны для разбора
полетов, то процесс импорта не является критичным по времени. Да и
при экспорте не нужно удалять данные в базе. Импортируйте, как Вам
удобнее: через TlgBackup или через ISQL. Хотя анализ данных не
обязательно делать в WinCC.
Описание на Storage Вы можете найти в рук-ве на BasicProcessControl
(содержится на любом из дисков WinCC). А лучше всего взять и
попробовать, благо без авторизации все работает в демо-режиме.
Re: На заметку разработчикам
СИМЕНС
Александр
Родин, ООО "Нева Электрик"; 27.12.01
Речь велась об экспорте в ASCII относительно DBASEIII.
С импортом я сам до конца заказчика не пойму... ну да ладно.
Требования есть требования - их выполнять надо.
Storage не очень подходит, потому, что, как я понял, он
экспортирует и импортирует данные с внешних носителей. А по заданию
мне надо вести сохранение на том же носителе, и иметь возможность
переноса сохраненных данных.
Вопрос до кучи: Я веду архивирование по принципу Ciclic Selective.
При этом включено архивирование по изменению (Upon Change)с
определенным гистерезисом. Допустим, переменная долгое время не
менялась. Время последнего значения давным давно уехало за пределы
фрагмента сохранения. После выполнения экспорта файл для данной
переменной будет пустым. Как можно этого избежать ?
Re: Запись параметров
siemargl; 3.1.02
---- 1.bat----
isql -q -c
"databasefile=E:\Siemens\Common\sqlany\sademo.db;userid=dba;password=sql"
1.sql
----1.sql----
select * from customer;
/*insert into customer (id) values (51);*/
delete from customer where id < 99;
---
etc
Re: Запись параметров
Alexis; 5.1.02
Привет Александр! :)
С Новым годом Вас и с наступающим Рождеством!
Извини, но дискутировать как раньше не могу, так как наша бедная
контора не может обеспечить нас инетом :(( вот... (может к себе на
работу возмете :) а то уж очень сильно я Невское Класическое люблю,
а у Вас наверное оно свежее, да на разлив)
Я построил свой дампер архивов следующим образом:
- это внешнее приложение (MS Visual C++ 6);
- имена архивов получаю через EnumArchive и EnumVariable;
- высасываю данные функцией GetArchiveDataEx - при этом теряю аудит
сбросов (но это мне и так до лампочки) - но выигрываю в том, что
записываю полученные данные куда хочу и как хочу! (функция
возвращает массив данных из выбранной таблицы);
- если данных за выбранный промежуток времени нет, то пытаюсь найти
последнее существующее значение связкой функций GetClosestTime и
GetArchiveDataEx.
Вот в принципе и весь алгоритм...
Да, название функций привожу так как они обозваны в моей
библиотеке, поэтому прибавляй к названию TLG и возможно где-то надо
вместо Archive читать Archiv :))
О производительности - сброс за час сотни посекундных архивов менее
двух минут... т.к. приложение внешнее то и в WinCC никаких
зависов... а у Вас наверное через скрипты? бррр...
С удовольствием выслал бы Вам эту программульку, но я не на
работе... :(
За сим прощаюсь...
Best regards, Alexis.
P.S. Когда-нибудь наверное прочитаю Ваши благодарности :))) если
конечно мой подход чем-нибудь вам поможет...
Re: Запись параметров
Александр
Родин, ООО "Нева Электрик"; 8.1.02
Hi, Alexis !
Вас так же с наступившими ! :)
На работу бы с удовольствием взял... Токма не я этим
распоряжаюсь...:) А так, ради бога - резюме рассмотрим. И
специалисты подобные нам нужны, и пиво "Невское" в обеденный
перерыв устроить можно. :)
Что касается процедур импорта-экспорта, да, интересное
предложение... И в достаточной степени простое решение... но для
опытного программиста. :) Я же в общем несколько иной аспект хотел
затронуть. А именно, почему я должен исхитряться и писать весь этот
механизм сам под WinCC, если скажем на других скадах он уже целиком
есть в виде полноценного приложения ? Опять же, на другие скады мне
переходить не выгодно, т.к. у них нет нормального драйвера для
сименсовских контроллеров. Вот и получается круг замкнутый... :(
Обидно блин.
В любом случае, спасибо за совет. Когда в достаточной степени изучу
VisC, может и воспользуюсь им... :)
Удач в новом году..
Re: Запись параметров
Dr. Kren; 10.1.02
Всем привет!
Пожелания успехов в неравной борьбе с разработчиками "SIEMENS"!
Пункт № 1.
Вся проблема с потерей управления - в кривизне ПО от SIEMENS и
прохладном подходе к разработке алгоритмов.
Дело, по всей видимости, в том, что процесс архивирования
выполняется самим ПО от SIEMENS без передачи управления процессом
архивирования внешнему приложению, запускаемому как отдельный
поток, либо внешнее приложение работает в контексте потока
приложения-родителя. В результате все поступающие от системы
сообщения (нажатия кнопок и т.п.) ставятся в очередь на
обслуживание процессом. А процесс пока обслуживает алгоритм
архивирования данных. Т.е. он полностью забирает на себя ВСЕ
ресурсы процессора, выделенные системой данному процессу.
В нормальных системах это решается левой ногой. Т.к. процесс
архивирования явно циклический
"SELECT что-то FROM откуда-то WHERE пока",
в нормальных системах подразумевается как минимум два варианта
отработки алгоритма.
Вариант 1-й. Приоритет процесса максимальный. До момента завершения
операции все остальное не важно. Это иногда полезно.
Вариант 2-й. Приоритет процесса нормальный. Архивирование
выполняется в фоновом режиме. Это полезно всегда.
Вариант 3-й (десертный. А кто не любит десерт?). Приоритет процесса
минимальный. Архивирование выполняется в моменты бездействия
системы. Это полезно как и вариант № 1.
Организовать назначение приоритета - задача тривиальная (знающие да
соображающие поймут сами, для остальных - переменная в контексте
окружения WinCC).
В случае максимального приоритета - поведение WinCC
закономерно.
В случае нормального (фонового) подход примерно следующий. Во всех
уважающих себя языках программирования под Win* (а, простите, какой
язык считает себя не уважаемым?) доступны функции WinAPI
"PeekMessage", "TranslateMessage", "DispatchMessage". С их помощью
организовывается процесс передачи управления остальным задачам
системы при каждом проходе цикла архивирования. В результате и
данные архивируются, и SCADA живет и здравствует.
В случае минимального приоритета процесса (вспомним о языках
программирования) обрабатывается состояние "Idle" системы
(простой). В этом случае процесс архивирования ВООБЩЕ не заметен
для пользователя и не мешает другим задачам.
Ну и, естественно, все вышеперечисленное (кроме варианта № 1)
возможно только в случае порождения нового процесса при запуске
алгоритма архивирования.
Так что, друзья, остается только посочувствовать Вам (не в обиду) и
себе за такие трудности, ну и разработчикам SIEMENS.DE (за их
IQ).
Пункт № 2.
Не надейтесь на SIEMENS & WinCC как на Господа Бога. Плюхи и
баги у них были, есть и будут.
Alexis поступает единственно верным в данном случае способом – сам
порождает новый процесс, не зависящий от WinCC. Что делает и ваш
покорный слуга (разница лишь в средствах MS Visual С ++ против
связки Delphi+InterBase).
Я вообще отказался от хранения таких объемов данных во встроенном
архиве. Там я храню только теги для отображения в трендах. Все
остальные теги я записываю во внешнее хранилище. И своими
собственными программами выдаю какие угодно отчеты и в каком угодно
виде. Набор инструментов - широчайший.
С уважением ко всем...
В том числе и "товарищам" из SIEMENS.DE
Re: Запись параметров
Alexis; 10.1.02
Привет Всем!
Александр, исхитряться и писать механизм импорта-экспорта вроде как
и незачем, так как Siemens предусмотрел опцию Storage. Вещь вроде
как работоспособная, но приспособленная только под конкретную цель
(типа сброса непрерывных архивов). Что мне в ней особенно не
нравится, так это то, что оно еще и дополнительных денег стоит.
Dr. Kren, к Вам маленький вопрос, что подразумевается под фразой
“хранение ТАКИХ ОБЪЕМОВ данных”? Имеется в виду что Вы используете
TagLogging для хранения только ProcessValueArchive, а функции
CompressedArchive берете на свои приложения?
Best regards, Alexis.
Re: Запись параметров
Dr. Kren; 10.1.02
Всем привет!
Пожелания успехов в неравной борьбе с разработчиками "SIEMENS"!
To Alexis
Несколько не так.
Все нужные теги для отображения как в трендах, так и в таблицах я
храню во встроенном архиве. Только архивы я делаю циклическими с
количеством записей 1 - 2 тысячи. И не более.
Параллельно этому архиву я веду свой собственный, в который
произвожу запись тех тегов, которые нужно хранить все время жизни
проекта. Например информация о расходе цемента, песка, гравия на
бетонном заводе. Вот эту информацию я и храню во внешнем
архиве.
На счет "ТАКИХ ОБЪЕМОВ" данных. Давайте посчитаем.
Для хранения одного значения во встроенном архиве требуется 28
байт. Хорошо. Что же там хранится?
1. Дата и время записи значения - 4 байта.
2. Само значение - 4 байта.
3. Что-то непонятное (либо 0, либо 64) - 4 байта.
4. Индекс для ускорения обработки запросов на выборку данных - 4 +
4 (в случае индексирования по дате и по значению двумя разными
индексами).
Итого 20 байт. Где еще 8?
И так на КАЖДОЕ ЗНАЧЕНИЕ ТЕГА, записанное в архив.
Я же группирую теги по событию записи в одну таблицу. Индексы по
значению мне и даром не нужны - важно корректно показать значения
на заданное время. В результате в 28 байт вмещаются
1. Дата и время записи значения - 4 байта.
2. Значение № 1 - 4 байта. (Double, DWord, SDWord)
3. Значение № 2 - 4 байта. (Double, DWord, SDWord)
4. Значение № 3 - 4 байта. (Double, DWord, SDWord)
5. Значение № 4 - 4 байта. (Double, DWord, SDWord)
6. Значение № 5 - 4 байта. (Double, DWord, SDWord)
7. Индекс для ускорения обработки запросов на выборку данных - 4
(индексирование по дате).
Во встроенном архиве эта же информация займет 28 байт * на 5
значений = 140 байт.
И чем больше тегов надо хранить, тем больше выигрыш.
При записи 5 тегов один раз в минуту имеем 28 * 60 * 24 * 366
получаем около 16 Mb за год. Пусть 20.
Во встроенном архиве то-же самое займет в пять раз больше, т.е.
около 100 Mb.
При 50 тегах встроенный архив съест около 1 Gb за год. В моем
случае это 100 Mb.
Вот это я и имел ввиду, когда говорил "вообще отказался от хранения
таких объемов данных во встроенном архиве" .
С уважением ко всем...
Re: Запись параметров
Dr. Kren; 14.1.02
Всем привет!
Пожелания успехов в неравной борьбе с разработчиками "SIEMENS"!
Сильно извиняюсь!
К предыдущему message
Структура записи Sybase ASA
1. Дата и время записи значения - TIMESTAMP 16 байт.
2. Само значение - DOUBLE 8 байта.
3. Что-то непонятное (либо 0, либо 64) - INTEGER 4 байта.
4. Индекс для ускорения обработки запросов на выборку данных -
минимум 4 байта. Индекса по по значению нет.
Итого 28 байт данных + 4 байта индекса.
С уважением ко всем...
Re: Запись параметров
Александр
Родин, ООО "Нева Электрик"; 24.1.02
Всем доброго времени суток.
Ответте пожалуйста на такой вопрос:
Для того чтобы производить сохранение данных требуется иметь
информацию об архиве, в котором хранятся значения переменных. Если
переменных немного, то задача решается просто - архив всего один.
Другое дело, когда их много (больше 50 для версии 4 или больше 300
для версии 5). Тогда более выгодно иметь несколько архивов. Так же
несколько архивов полезно иметь в случае, если архивирование
ведется с разной идеологией (циклическое, ациклическое, с разными
циклами опроса и т.д.). Как правило сохранять надо сразу кучу
переменных, причем из разных архивов. И вот здесь-то и возникает
проблема. А как произвести такое сохранение за один цикл ?
Естественный напрашивающийся ответ - создать массив, в котором
хранить данные по каждой из архивных переменных (к какому архиву
принадлежит, полное SYBASE-имя, на какой процессный таг ссылается).
В принципе такой массив можно создать какой-нибудь
инициализационной функцией и сделать его доступным для других
функций ("С" это делать умеет, а WinCC поддерживает такую
возможность). Второй путь - создать некотрое количество внутренних
тагов по числу архивных переменных и так же заполнить их
посредством инициализационной функции. И наконец третий путь - это
создать файл-список, в котором так же хранить данные об архивных
переменных.
Каждый из этих способо в чем-то лучше, в чем-то хуже. Но вот
хотелось бы узнать мнение опытных разработчиков, какому способу
отдать предпочтение.
Заранее спасибо.
Re: Запись параметров
Alexis; 8.2.02
Александр, вот тебе еще и четвертый путь :)
При конфигурировании архивов занеси в поле Comment или Unit (в
принципе все зависит от фантазии разработчика :) какую-нибудь
идентифицирующую информацию. Далее перед сбросом данных считывай
информацию об архиве и анализируй идентификаторы относительно
которых и производи сброс.
Единственный минус подхода - считывание данных об архиве процесс
медлительный.
Re: Запись параметров
Александр Родин, ООО
"Нева Электрик"; 21.5.02
2 Alexis:
Собссно, вот и воткнулся на те самые грабли... Как вот теперь этот
4-й путь реализовать ?.. :)))))) Вроде и функция есть, а
использовать ее никак...
Re: Запись параметров
Alexis;
21.5.02
2 Александр Родин
>Вроде и функция есть, а использовать ее никак...
Это точно, особенно если установленна только RT. Повозившись с
TLGReadVariable пришлось на нее плюнуть и обойти эту проблему
прямым чтением (db.dll) из CS-ной базы, но и тут трабл, никак не
могу подключится к CS-ной базе с клиента. Поэтому моя софтинка пока
может жить только на сервере :(
Re: Запись параметров
Александр Родин, ООО
"Нева Электрик"; 21.5.02
2 Alexis:
А если проект однопользовательский, то надежда есть ?.. %)
Надо будет попробовать...
Re: Запись параметров
Alexis;
22.5.02
В однопользовательском все работает нормально :)