Сбилась кодировка в DBF файлах (исп 7.49)

Slaventy

После обновления на версию Сеть Плюс 10 7.47 в DBF файлах сбилась кодировка, в связи с этим полностью нарушилась работа в 1С Бухгалтерии. 1С не понимает крокозябры.
Красным цветом выделены заказы списанные после обновления. Зеленым цветом - до обновления. Помогите работа встала.
HELP!!! HELP!!! HELP!!!

Владимир

это со всех машин сети такое?

думаю стоит попробовать выгрузку с разных, плюс удалить все dbf и выгружать в чистые

Slaventy

Да со всех!!! Попробовал сделать новую выгрузку. Теперь вся выгрузка в крокозябрах.

Владимир

ну это 100% ваш местный глюк, у меня 47 версия месяц наверное работала и все было отлично, сейчас 48 и тоже никаких жалоб

Slaventy

Сисадмины утверждают, что это глюк RASKONa. Что при выгрузке в DBF файлах в программе поменялась кодировка.

Владимир

ну почему тогда у меня не поменялась?

Slaventy

Интересно!!! Поэкспериментировал и вывел некоторую закономерность.
Дело в том, что недавно в код (номер) заказа мы ввели один латинский символ (по незнанию). Раньше например наши заказы кодировались так 50566Б (где 50-номер точки откуда поступил заказ, 566-порядковый номер заказа с этой точки, Б-буква партии заказа в определенную смену). Теперь к этому коду (номеру) заказа мы добавили латинскую букву V, которая у нас стала обозначать определенную принадлежность заказа. Так вот если из справочника заказов списывать заказы и в список попадает заказ с буквой V, то все заказы списываются в файлы DBF "кракозябрами", если в списке нет заказа с лат. буквой V, то заказы списываются в файлы DBF нормально. Вывод: Или нельзя использовать лат. символы, или нельзя совмещать русские и латинские символы.

Интересно, что об этом думает разработчик?

Владимир

у нас номер вида 1111_11_2009D, с русскими нет и никогда не было. думаю причина кроется не здесь

Интересно!!! Поэкспериментировал и вывел некоторую закономерность.
Дело в том, что недавно в код (номер) заказа мы ввели один латинский символ (по незнанию). Раньше например наши заказы кодировались так 50566Б (где 50-номер точки откуда поступил заказ, 566-порядковый номер заказа с этой точки, Б-буква партии заказа в определенную смену). Теперь к этому коду (номеру) заказа мы добавили латинскую букву V, которая у нас стала обозначать определенную принадлежность заказа. Так вот если из справочника заказов списывать заказы и в список попадает заказ с буквой V, то все заказы списываются в файлы DBF "кракозябрами", если в списке нет заказа с лат. буквой V, то заказы списываются в файлы DBF нормально. Вывод: Или нельзя использовать лат. символы, или нельзя совмещать русские и латинские символы.

Интересно, что об этом думает разработчик?

Похоже ошибка гдето именно в этом. Я на этот процесс никак не влияю, возможно это драйвера доступа к базам данных както сами неграмотно переводят "юникод". Я постараюсь встроить принудительный перевод "юникода" в "анси" в нужную кодовую таблицу, соответсвенно с настройкой в программе кодовой таблицы для экспорта.

P.S. В настройках среды на закладке "прочие", есть группа настроек для нумерации заказов и там можно выставить у дилеров коды одразделений, разделитель.... Вы наверно эту возможность используете.

Вам помогли исправления сделанные в версии 7.49?

Slaventy

Спасибо. В общем после обновления ошибка пропала на 99%.
Очень странно, но теперь не могу вычислить закономерности.
Из 100 заказов один списывается кракозябрами, если его в ручную удалить из DBF-файла и опять списать, то в 97% это помогает и он опять списывается нормально. Но теперь появилась еще один баг со списанием.

Например:

Конструктор забил заказ и списал его в DBF. В этом заказе, например, обнаружилась ошибка - конструктор поставил не ту фурнитуру. Заказ исправляется, сохраняется и списывается заново для корректировки материалов в DBF-файлах. И вот в этот момент программа сообщает об ошибке. Причем это происходит не всегда, закономерности не выяснил, иногда программа просто затирает старый заказ исправленным как и должно быть. Ошибка возникает в 100% случаех при списании на главном компе. И в 50-60% при списании на сетевом рабочем месте.

НЕПОНЯТКИ!!!

Конструктор забил заказ и списал его в DBF. В этом заказе, например, обнаружилась ошибка - конструктор поставил не ту фурнитуру. Заказ исправляется, сохраняется и списывается заново для корректировки материалов в DBF-файлах. И вот в этот момент программа сообщает об ошибке. Причем это происходит не всегда, закономерности не выяснил, иногда программа просто затирает старый заказ исправленным как и должно быть. Ошибка возникает в 100% случаех при списании на главном компе. И в 50-60% при списании на сетевом рабочем месте.

Ошибка КАКАЯ?