Consul1111
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору M_Volkov Попытка/Исключение есть. Я наверное очень сумбурно объясняю. Есть завод с АСУ ТП, у асу база крутится на файербёрде. Есть диспетчер который сидит в этой же локальной сети, от асу нужен только функционал управления заводом, всю аналитику производит 1цЭ, чтобы по максимуму исключить человечий фактор, я лет 8 назад написал конфигу диспетчеризации, которая кидает данные напрямую в асу, в её базу, а потом получает взад некий результат, чтобы по 2-3 раза не заносить одни и те же данные, реализовано заполнение справочников в асушке из 1с, программно, туда пишет без проблем, но при повторной отправке и сравнении этих же данных, 1с считает что вот эти строки не равны, хотя сама же их туда (в бд файербёрда) записала. Всё это успешно трудилось эти годы, но пришла беда откуда не ждали, мы купили новую производственную линию, та же асу, но более свежей версии, уже весь код перелопатил, всё работает, кроме вот этого момента, 1с считает что строки не равны и записывает новый элемент в базу асу. Понятно что всё это на копиях тестится, но близится день запуска, а код неоптимален. Вот и задал вопрос, может кто-то сталкивался с сравнением строк и похожей проблемой? Скорее всего это из-за кодировки, скажем на 95% в этом уверен, но вот как победить, не знаю. Переходить на латиницу в атомобильных номерах не предлагать, поле ключевое и это всё синхронизируется с ещё двумя конфигами от 1с на 7.7 и БП 3.0, ну и самое главное - диспетчер не будет менять раскладку клавиатуры при внесении гос номера. Добавлено: ЗЫ обмен через ADO драйвер FireBird 2.0.5, сам FireBird 2.5 Добавлено: Нашёл ошибку, когда копипастил, вставил лишний оператор MoveNext() |