Доброго дня, коллеги.
Пытаюсь передать данные таблицы из одной базы в другую с модификацией поля atl_branch. Получил файлы *.dbf, пытаюсь модифицировать
var hFile : longint;
sFileFull:= GetFirstFile('C:\SupCl','*.dbf')
while sfilefull <> strDataIsEmpty do {
hFile:= DBFOpen(sFileFull, stOpen);
if DbfGetFirst(hfile) != 0 message('GetFirst is bad');
else
do {
if DBFPutFieldValue(hfile, 'ATL_BRAN', '281474976710657') = 0 message ('DBFPutFieldValue is good')
DBFUpdateRecord(hfile)
message('DBFGetFieldValue = '+DBFGetFieldValue(hfile, 'ATL_BRAN'))
} while DBFGetNext(hFile) = 0
DBFClose(hFile)
sfilefull := GetNextFile;
}
Имею две ошибки:
1. Поле 'atl_branch' не воспринимается функциями DBFPutFieldValue и DBFGetFieldValue из-за длины > 8. Обрезал в редакторе до 'atl_bran', тогда ошибка ушла. А как программно обрезать?
2. Функция DBFPutFieldValue(hfile, 'ATL_BRAN', '281474976710657') возвращает 0, но записывает 2
Обошёл так проблему: перед выгрузкой в dbf делаю модификацию atl_branch в тестовой базе. Работает.
Выявилась ещё одна проблема: при импорте из dbf система подставляет не тот филиал, который был в dbf файле!
Здравствуйте.
Давно не работала с DBF форматом ) Вы столкнулись с проблемой ограничения длины имени поля в DBF файле. А у меня еще была проблема при экспорте из Галактики полей, которые в своем имени имеют символы [ или ] (запрещенные для dbf), например Oborot.Tblos[1]. С такими именами не получалось работать. В этом случае приходилось вручную менять эти символы или убирать их непосредственно в FoxPro при корректировке структуры. Другого выхода тогда не нашла.
Есть проблема с полями типа Comp, их лучше экспортировать как символьные, в cfg для этого прописывается Lot.ExportCompToStr=True.
А по поводу подстановки не того филиала, что в dbf файле, при импорте. Так причина наверное в том, что в dbf файле Вы имя поля atl_branch предварительно изменили на atl_bran. Поэтому при импорте соответствие по именам не установлено и значение филиала заполняется тем, которое соответствует филиалу, на который настроена система. Т. е. если Support или Галактику Вы запустили по филиалу со значением nrec1, в dbf же nrec2, то и при импорте заполнится nrec1. Думаю, что так.
Может для обмена данными использовать другой формат, а не dbf?
Скорее всего проблема с некорректной установкой atl_branch лежит глубже.
Если попробовать просто модифицировать это поле обычным запросом, то ничего не произойдет. Необходимо добавлять SetBranch.
<игнорировать-филиальность> — конструкция setBranch, позволяющая менять поле Atl_branch независимо от текущего значения филиальности. См. также Функции для работы с филиальностью. Конструкция используется только в операторах insert и update.Доступна начиная с Атлантиса 5.3.18.
<игнорировать-филиальность> = setBranch [ (<условие>) ]
<условие> — опциональный параметр setBranch, включающий этот режим при истинности выражения. Может использоваться для написания общего кода, когда заранее неизвестно, надо вручную выставлять Atl_branch или нет.
Если <условие> истинно или отсутствует, то система будет в модифицируемых записях устанавливать поле Atl_branch, заданное прикладником. В противном случае поле Atl_branch будет заполняться системой в соответствии с текущей настройкой филиальности.
Помимо указания ключевого слова setBranch необходимо также обычным способом задать значение Atl_branch:
T.Atl_branch := xxxh;
update setBranch current T;
или
insert setBranch(true) Appendix set Atl_branch := 3;
Если значение Atl_branch не задано (фактически, если поле не изменено), то несмотря на наличие конструкции setBranch значение Atl_branch будет стандартным.
Исключение: конструкция insert setBranch <table> set <операторы-присваивания>, где в <операторах-присваивания> отсутствует Atl_branch. В этом случае значение Atl_branch будет равно 0. Эту особенность впоследствии планируется изменить на стандартное поведение.
Вложенная выборка данных (insert from select, update where) в любом случае будет происходить в соответствии с текущими филиальными ограничениями.
На точки расширения, прикладные триггеры, модификации из Pascal данная конструкция, заданная снаружи, действовать не будет.
Для таблиц, открытых в памяти, заполнение Atl_branch работает в режиме WriteThru (сразу в БД пишется указанное значение) или при MTGetNextNRec(<table>, true). В последнем случае указанное значение пишется в ТП, а в БД попадает на этапе Flush, ручном или автоматическом.
Пример.
Во всех вставляемых и изменяемых записях полю Atl_branch будет присвоено значение 1 вне зависимости от наличия филиальности, текущего филиала(ов), динамически переключенных филиалов (с помощью SetBranches):
set atl_branch=1;
insert current setbranch mytable;
insert current setbranch mytable set atl_branch=1;
atl_branch:=1;
update current setbranch mytable;
modifyfilials:=true;
update setbranch(modifyfilials) mytable set atl_branch=1 where ((myvalue==mytable.myfield));
Если dbf получается из сапорта, то вы можете поcтавить параметр lot - ExportCompToStr, если через экспорт в галактике можно попробовать поменять тип поля, или сделать вычисляемое поле, например string(Katorg.nrec,0,0). Про импорт уже написали. Можно также попробовать в мультифилиальном формате.
Длина имени поля по стандарту 10.
Можно изменить добавив в секцию lot
DBFFieldNameSize=24
- заодно исчезнет проблема импорта длинных полей сапортом (после подрезания до 10, могут получится не уникальные имена). При конвертации используется именно этот параметр.
Но после этого файл не будет открываться никаким редактором, кроме импорта в галактику.