суббота, 28 августа 2010 г.

C 1 августа работаем с SQL Server 2005

Июль 28th, 2010

Не парсится запрос по нарядам в db2. Х.з. когда исправят. Времени нету ждать.

Первый день с Db2 под нагрузкой пройден

Июль 15th, 2010

Пользователи не испытывали проблем. Главный бухгалтер провел документ с 4000 строк без дробления, чем был несказанно удивлен и обрадован. Db2 форэвэ….

Бакап пока делаю ручками. С загрузкой выгрузкой пока ладушки. А с учетом того, что 1С8_SRV и DB2 на одном физическом серваке, ваще вау…

Сегодня 14 июля 2010 после летней грозы

Июль 14th, 2010

Сегодня 14 июля 2010 после летней грозы решил мягко перейти на db2. PostgreSQL просто зае своими взаимоотношениями с 1С8. Не хочу больше вымучивать и выстругивать…

PostgreSQL: Out of memory при восстановление из резервной копии

Июль 11th, 2010

С некоторых пор появилась напость. Восстановление из резервной копии *.backup возвращает ошибку 1 – Out of memory при попытке скопировать таблицу config, запись 798… Интересно, что создание копии порой проходит с возвратом 0, но очень редко. Анализ ошибки показывает, что размер указанный в поле записи datasize типа integer составляет значение на 2 порядка больше остальных – 111 967 964 (и на 3 порядка больше остальных, если не считать еще одного большого 6 071 329). Все остальные 16-17 тысяч записей имеют это значение от 10 до сотен тысяч. Еще одна странность поле имени файла этой злополучной записи содержит в два раза более длинное имя (если обычное 32 символа) – 64, как задвоенное. Будем слать в поддержку 1С за разъяснениями, удалить запись или исправить как-то.

Получаем через ком интерфейс данные о начислении ЗП

Июнь 6th, 2010

1C8.2 Комплексная конфигурация, пока в режиме 8.1.



Задача: Написать внешнюю w32 программу для обработки данных о начислении зарплаты в 1С8.2 КК в целях начисления премий по особому алгоритму и хранения их для последующего анализа.

Действие 1: Вытянуть данные о начислении ЗП в разрезе подразделений, сотрудников, видов начислений, периодов начислений, с учетом того, что документ проведен и не помечен на удаление. Часть данных находится в табличной части документа – Начисления.



Конектимся…



KomSRV:=CreateOleObject(‘v82.ComConnector’);

v0:=KomSRV.Connect(‘Srvr=”192.168.0.xx”;Ref=”Postgresql-server”;USR=”админ”;Pwd=”xxxxxxxxx”‘);


Используем лобовую атаку для пребора табличной части, перебор списка документов не вызывает проблем…

Берем документ 113

v1:=v0.Документы.НачислениеЗарплатыРаботникамОрганизаций.НайтиПоНомеру(‘00000000113′,’20100505′);

//ShowMessage(BoolToStr(v1.Проведен)); // если -1 то проведен, если 0 то нет

//ShowMessage(BoolToStr(v1.ПометкаУдаления)); //если -1 то помечен на удаление, если 0 то нет

//ShowMessage(v1.ПериодРегистрации);

//ShowMessage(v1.Организация.Наименование);

//ShowMessage(v1.ПодразделениеОрганизации.КПП);

//ShowMessage(v1.Комментарий);

//ShowMessage(v1.КраткийСоставДокумента);

//ShowMessage(v1.ПериодНачисленияДатаНачала);

//ShowMessage(v1.ПериодНачисленияДатаОкончания);

//ShowMessage(v1.Начисления.Количество()); //количество записей табличной части Начисления документа НачислениеЗарплатыРаботникамОрганизаций

for i := 0 to v1.Начисления.Количество()-1 do //перебор табличной части Начисления

begin

v2:=v1.Начисления.Получить(i); //вот так у меня получилось указать на очередную строку табличной части Начисления с возможностью получения данных реквизитов типа NEXT

ShowMessage(v2.Сотрудник.Код);

ShowMessage(v2.Сотрудник.Наименование);

ShowMessage(v2.ПодразделениеОрганизации.Наименование);

ShowMessage(v2.ВидРасчета.Наименование);

ShowMessage(v2.Результат);

ShowMessage(v2.ДатаНачала);

ShowMessage(v2.ДатаОкончания);

end;
Теперь можно перебором документов с учетом периода и видов расчета, а также учетом проведения и пометок удаления (а внутри каждого перебирать табличную часть) вытащить данные в любой датасет и там уже выполнить спецобработку…



Вроде нехитро, но помучился тыканьем :)

Странное сообщение...

Май 29th, 2010

В 00:00 -00:01 в логе видим что-то подобное



Can’t find mchar/mvarvarchar types: mchar=0 mvarchar=0 STATEMENT: SELECT tableoid, oid, lanname, lanpltrusted, lanplcallfoid, lanvalidator, lanacl, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = lanowner) as lanowner FROM pg_language WHERE lanispl ORDER BY oid


LOG: Can’t find mchar/mvarvarchar types: mchar=0 mvarchar=0


STATEMENT: SELECT tableoid, oid, proname as aggname, pronamespace as aggnamespace, pronargs, proargtypes, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = proowner) as rolname, proacl as aggacl FROM pg_proc WHERE proisagg AND pronamespace != (select oid from pg_namespace where nspname = ‘pg_catalog’)
и т.д.

Замечено, что в выходные дни сообщения эти отсутствуют, т.е. если в базу не вносились изменения, то и процедура, ответственная за сообщения не запускалась.

Сначала думал, что это autovacuum. Отключал его в конфиге

autovacuum off
Результат нулевой.

Теперь попробуем там же изменить уровень логирования до Debug1

log_min_message debug1


Пошла более частая инфа в лог, но ситуация не прояснилась.

Теперь попробуем изменить уровень детализации ошибок на verbose (подробно)

log_error_verbosity verbose
Оп-па, ловля блох удалась.

LOCATION: fillMCharOIDS, .\src\backend\optimizer\path\indxpath.c:2031

Вот она функция (процедура) выдающая это сообщение. Она содержится в патче 1С, который

содержит дополнительные модули расширения и необходимые изменения к СУБД, добавляющие функциональность, необходимую для работы с сервером 1С:Предприятия 8.1 и 1С:Предприятия 8.2

В части

ROUTINES FOR “SPECIAL” INDEXABLE OPERATORS FOR SPECIAL USER_DEFINED TYPES
и похоже выдает сообщения о неиндексированных блоках данных, что есть не смертельно, хотя зачем эта инфа пользователю – не понятно.

Пока.