11.08.2003, 13:10 | #1 |
Участник
|
Номера строк в таблицах Purchase Line и Sales Line
Может быть кто-то разъеснит мне одну загадочную вещь. Не то что бы это проблема, но очень хочется понять.
В таблицах 37 и 39 (это фактурные части документов продажи и покупки) есть ключевое поле Line No. (integer). Если пользователь создает строки в этих таблицах из формы (ну, например, Заказ), то это поле заполняется автоматически, т.к. у формы стоит свойство AutoSplitKey=Да. Но почему автоматически присваеваются такие странные номера: 10000, 20000 и т.д. Почему именно такие? Мне необходимо создавать строки в этих таблицах программно и я не уверена будет правильно просто присваивать им такие номера по порядку (10000, 20000, 30000...). Кстати с этим полем еще одна загадочность есть. Если программно вставить запись с Line No. = 0, то при любой пользовательской попытке изменить или удалить такую строку Navision просто вылетает. Буду благодарна за любые соображения по этому поводу. |
|
11.08.2003, 13:30 | #2 |
Участник
|
Не знаю почему это кажется загадочным. Просто эта нумерация строк програмно задана разработчиками Navision.
А насчет того, чтобы создавать эти строки програмно, то именно так и надо 10000, 20000... Если вы мне не верите попробуйте сами, попытка не пытка.
__________________
Александр Игнатьев |
|
11.08.2003, 13:34 | #3 |
Участник
|
через 10000 идет нумерация что бы между строками потм можно было еще
что-нибудь воткнуть к примеру при раскрытии комплекта вместо одной строки появляются все строки комплекта |
|
12.08.2003, 07:07 | #4 |
Участник
|
Ну ладно, на счет нумерации убедили. Наверное это, действительно, обоснованно. Всем спасибо!
А по поводу строк с Line No. = 0? |
|
12.08.2003, 11:24 | #5 |
Участник
|
Line No. = 0 возникает обычно в тех случаях, когда заполнение табличной части выполняется при помощи некорректно написанного программного кода
Если использовать стандартные методы Navision, т.е. AutoSplitKey и DelayedInsert, то все ОК. Обратите внимание, что в стандартных документах поле "Строка Но." недоступно пользователю. Кроме того, в тригере OnRename соответствующей таблицы присутствует код : ERROR(Text001,TABLECAPTION); где Text001 = 'Вы не можете переименовать %1'. |
|
13.08.2003, 08:21 | #6 |
Участник
|
Rungart, я прекрасно понимаю, что Line No. = 0 - не есть нормальная ситуация, и что при пользовательской работе такого в принципе не может быть (если не изменять код, конечно). Но не кажется ли Вам странным то, что всего лишь из-за одного неправильного заполнения поля (программно), весь Нави напрочь падает?!
На переименование таких записей, действительно, стоит ERROR, а как на счет удаления? Я бы поняла, если просто не удалял, а то ведь аварийно закрывается... |
|
13.08.2003, 10:26 | #7 |
Участник
|
Хотите хохму?
Зайдите дизайнером в любую форму с табличной частью, затем установите курсор мышки на разделитель строк в гриде так, чтобы он превратился в вид "стрелочка вверх/вниз" и нажмите правую клавишу мышки. Надеюсь у Вас все было сохранено? Эта ошибка существует с версии Navision Financials 2.00 , в центральном офисе о ней знают. Ошибка Line No.=0 известна уже очень давно, однако со стороны Navision реакция отсутствует. Когда вышла 3.70 и говорили о массе исправленных ошибок (несколько десятков листов) я надеялся, что подобные вылеты будут исправлены .... Наивный! |
|
13.08.2003, 12:56 | #8 |
Участник
|
Ясно ..... присоединяюсь к сожалениям :-(
|
|
13.08.2003, 13:22 | #9 |
Участник
|
Цитата:
Изначально опубликовано Rungart
Когда вышла 3.70 и говорили о массе исправленных ошибок (несколько десятков листов) я надеялся, что подобные вылеты будут исправлены .... Наивный! Не отчаивайтесь, Rungart, указанные вами ошибки исправлены в 3.70 fin.exe 5149848 (размер); finsql.exe 5235864(размер). Если вы смотрели только в доку с исправлениями, то проверьте на практике. Правда 0 строка приводит к переполнению стека, но это уже не так страшно и исправляется легко. Самое приятное, что оболочка не поднимает версию базы и можно работать в оболочке 3.70 с базой 3.60. Удачи |
|
13.08.2003, 14:44 | #10 |
Участник
|
Будем с нетерпением ждать первого квартала 2004 года, когда будет готова 3.70 RU.
Надеюсь, что релиз не будет перенесен на более поздний срок в связи с громадными планами по локализации . |
|
13.08.2003, 15:30 | #11 |
Участник
|
Что-то я не верю, что что-либо будет исправлено. Вспомните только ситуацию с трассировкой. Сколько раз говорили, что она исправлена. И что исправлена?
__________________
Александр Игнатьев |
|
13.08.2003, 15:54 | #12 |
Участник
|
Цитата:
Изначально опубликовано sash_xp
Что-то я не верю, что что-либо будет исправлено. Вспомните только ситуацию с трассировкой. Сколько раз говорили, что она исправлена. И что исправлена? У Вас тоже было два, а остался один: проверить |
|
14.08.2003, 14:46 | #13 |
Участник
|
Небойтесь!
Ошибок Хватит и на версию 3.8, 3.9..... |
|
14.08.2003, 15:01 | #14 |
Участник
|
Цитата:
Изначально опубликовано sash_xp
Не знаю почему это кажется загадочным. Просто эта нумерация строк програмно задана разработчиками Navision. А насчет того, чтобы создавать эти строки програмно, то именно так и надо 10000, 20000... Если вы мне не верите попробуйте сами, попытка не пытка. А где она задана, можно ее найти? Потребовалось создать таблицу с таким же принципом нумерации строк, пришлось мягко говоря извращаться, как вспомню, так вздрогну от стыда |
|
14.08.2003, 16:19 | #15 |
Участник
|
1. Проверить, чтобы последнее поле ключа имело тип Integer
2. В субформе установить свойства : AutoSplitKey = Да DelayedInsert = Да 3. Запустить. Интервал с другим шагом задать нельзя |
|