Непонятное поведение периодического реквизита справочника. 1с77, sql, Зик. Справочник "Штатное расписание" Реквизит ВилкаМин, ВилкаМакс. При установке значения реквизита с дробной частью происходит непонятная картина. Установил значение 28.5 при записи программа сохраняет значение 28.5 в таблицу БД (проверил в табличке именно 28.5), но после записи при обновлении формы сама устанавливает значение 9! После закрытия элемента и открытия, то значение стоит то, что было установлено 28.5. Теперь если открыть форму редактирования истории периодического элемента там стоит значение 29. И при попытке его редактировать, как только вхожу в режим редактирования значения программа автоматически устанавливает значение 9! и не дает установить значение отлично от типа Число 1.0. Как быть, что делать!?

мистика

где хранится размерность поля периодического реквизита в sql?

(2)Там же, где и в DBF, в константах :)
1С не потрудилась

(0)Зик - О_о... вы знатные извращенцы.
Вертай ЗиК обратно в DBF и спи спокойно ;)

(1) уже все перепробовал, вопрос то вроде плевый, но ни фига
(3) не там только инфа о том что это число, типа 'N ....', а сама размерность числа?

(4) это до меня сделали, я уже матюгался по этому поводу, не прокатило, все равно переходим на 1с8, так что сильно не упираюсь, просто при этом преславутом переходе значения именно и будут 29 а не 28.5 проверено.

(5)Все там же, 1С 7.7 еще проще 8-ки, так что все в одном поле 23 символьном :)
(6)Не мучай ОПУ, верни в DBF, у вас тут же решатся куча проблем.
Ну, конечно, если уже не успели подсесть на прямые запросы :)

+ >>> будут 29 а не 28.5 проверено.

Даже не буду вдумываться, ЗиК на SQL это уже ДНК, того кто это сделал :)

(8) а ты уверен, что на ДБФ оно будет правильно работать? Такой изврат, как периодический реквизит неопределённого типа, может же не проканать

(9) уверен, я перегнал в ДБФ, сначал отработало не правильно, но после принудительной установки значения реквизита из истории, все встало на свои места.

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

(9)Я про ЗиК на SQL познал на собственной шкурке :)

(12) у нас зик на скуле работает нормально. что мы не так делаем?

(13) честно? однозначно сказать сложно, что будет, но вот тебе мой пример.
Да и зачем скуль то, смысл? Чтобы копию БД снимать по 3 часа, когда в ДБФ она снимется в течении 15 минут? Единственный минус что не требует пере индексации при падении 1С, а так она медленнее, чем ДБФ.

(14) Копия БД на скуле за 3 часа? О_о
10 минут + копирование каталога базы... И плевать на юзверей...
+ прямые запросы.
+ надёжность.

(15) я делаю выгрузкой БД, а ты чем?
+ вот тебе пример, и даже не знаю чего сделать? где надежность?
Прямые запросы и в DBF есть 1срр.

(16) А я делаю правильным способом - бекапом базы...

А прямые запросы в дбф - это третье извращенье (см ветку про Раневскую)

(17) взял, поднял ветку :-))))

Тогда еще сюда напишу:
1с77 ЗИК SQL. Для периодического реквизита неопределенного типа в режиме редактирования программно устанавливает тип значения число.10.3. После записи тип реквизита произвольно устанавливается в число.1.0. Выгляди так: создал новый элемент , установил значение типВилки, при установке значения отработал установки формата реквизита ВилкаМакс. Установил Значение 34.5. Записал без закрытия. После записи в реквизите уже просто 4 т.е. 3 и 5 справа слева он обрезал. Смотрел отладчиком до конца процедуры ПриЗаписи() значение остается равным 34.5. Мистика?

(15) А нафига прямые запросы в ЗИКе нужны?

(17) а бэкап делаешь скульными средствами?

(20) А не думал, что зик - это не только фискальная зряплата?

(21) я же написал - правильным...

(18) Ибо нефиг плодить...

(15)>>> +прямые запросы
Ах подлец, переписал ЗиК, как бог черепаху.
И хвастается, "В чем проблема?"

Проблема в трудо-затратах на сопровождение этого чудовища :)

(20)А на 1С-ых запросах, в SQL версии, ЗиК не пашет, или пашет медленно и неустойчиво :)

(26) тоже переписано :-) да как то кривовато, предыдущий программист обновления вручную накатывал.

(27) И что вы там переписывали? В ЗИКе на сколько я в курсе главный тормоз это выбратьпозначению, которое на скуль перекладывается очень криво.

(19)Все зависит от того, а какая длина назначается для этого реквизита :)
В общем, если ты объявляешь тип Число для длиной 9, то точность может быть не больше 8-ми, т.е. длина это и есть полная длина с дробной частью и запятой.

(28)не смогу все перечислить, может быть и выбрать по значению, проблема то все равно в САБЖе :-)

(29)тип значения число.10.3

(31)Пиши, 14.3, тогда взлетит :)
А для простоты пиши 23.3

+(31)10.3 - считай что у тебя целая часть всего 7.3

или даже 6.3

(34)да, позиция под зпт.

(32) не помогло, даже так перед записью стояло значение  2.000, после записи стало 2.0.

(35)Ну тогда что тебя удивило?
Если у тебя целое число сжирает все или дробная часть не лазит.

В общем, ЗиК на DBF, а ну их перепись запросов.
+ Никогда не вносить глобальные дописки в ЗиК, ибо это чревато головной болью.

(36)"Дядя, ты идиот" (с)

Без обид, но ты в курсе, что стоит писать к примеру число: 2.001 :)
И еще я же не вижу, возможно если ты помещаешь это значение еще в какой реквизит, ограниченной длины, то ХЗ. Может и ловишь свою урезку.

Приэтом у тебя же еще и периодический реквизит, то возможно в том периоде, это число уже объявлено до двух знаков :)

(37) не пойму, что съедает ввел число 2 формат число 14.3. Я так понимаю что после записи происходит внутрення функция типа Перечитать()в 8-ке, и значения берутся прямо из БД движком.

+ "Нам от сюда не видно"

(39)Этот реквизит же в справочнике, вот и ищи его там.
Кто этот справочник юзает :)

Справочник ШтатноеРасписание вилкаМакс там "Неопределено".

Прикол в том , что в DBF версии метод Периодический.НазначитьТип("Число",10,3) отрабатывает корректно, а в sql вообще не работает!

(42)Чудес не бывает...

(43)Ты будешь смеяться, но это не работает только в ЗиК :)

(45) как это отписать корректно? так чтобы еще и коллеге - "руководителю", который работает на Axapta пояснить? Он в 1с ни ногой (.

(46)Ты же провел эксперимент, перевел БД из SQL в DBF, ошибка пропала.
Так и пиши...

Но для теста, запусти ТиИ :)

Ну и еще, я про то что на SQL не корректно работает журнал расчетов.

(47) в данном случае журнал расчетов ни каким боком, ладно, как нить от пинаюсь, все равно скоро переход на 1с8. Спасибо за помощь, Человечище Души :-)