v7: SQL 2008 + 7.7 Нумерация документов???? #588274

Перенес базу на сабж.. была ф дбф версии. При создании документов не всегда выполняется инкремент номера-документа.??? =8- что за нах? т.е. чел создает новый документ (счет например) набивает в него товар и при сохранении ему соббщают, что номер не уникальный. и действительно уже есть документ с его номером.

Документы за один день. Без разницы, что для документов с собственным нумератором, что без.

а что говорит товарищ профайлер?

мож распределенка? у мну на 2008 всё гуд, таких проблем не наблюдаю

не понял, что конкретно посмотреть? база древняя. единственное, что в ней идет это ежеминутное создание документов ~50ю пользователями.

при создании базы возникала ошибка с "доступ к базе данных возможен только из одного каталога информационной базы", решилась новой bkend.dll

вроде как специально под 2008 и 7.7 а сегодня первый день и уже такая засада.. =(

при создании нового документа смотри 2 вещи 1. создание файла блокировки (в каталоге базы) 2. запись в таблице выделения номеров (имя таблицы зависит от нумератора) потом выгони всех и смотри сново, таблица выделения нумеров должна быть ПУСТАЯ если ни кто не создает документ

Проблема нумерации доков при переходе одного года в другой ни как не связан со скулем я так думаю. Вот что я писал всем нашим юзерам сегодня Ликбез для 1С-пользователей. В любой программе 1С Предприятие  есть понятие "Рабочаядата". Установив "Рабочую дату"  на определенную дату пользователь имеет возможность вводить документы на указанную дату без дополнительных корректировок. допустим пользователю необходимо ввести 20-30 документов задним числом. Реальная дата 5 января  а необходимо ввести документы на 3 января. Установив Рабочую дату на 3 января пользователь не беспокоится о смене даты каждый раз. Аналогично при необходимости ввести данные ранее чем определенная дата то установка рабочей даты например на 31 янавая 2012 года позволяте без проблем вводит документы будущей датой.  Как установить Рабочую дату??? Меню "Сервис", "Параметры", "Рабочая дата" "Ок" !!!  Данная проблема осторо встает при переходе на новый год когда как правило необходимо вносить данные за прошлый год. При вводе новых документов нумерация с новогогода автоматически идет с начала  000001 итп. Но при попытке сменить дату на прошлый год номер становится не уникальным поскольку в том году этот номер был введен еще в начале прошлого года. Как раз чтобы избежать такую проблему есть смысл установить рабочую дату на прошлый год. Но!!! Не забудьте поменять  рабочую дату если вы намерены вводить документы уже текущего нового года. Иначе находясь по рабочей дате в прошлом году вы введете новый документ допустим "перемещение" под номером 00093456 при смене даты на новый год номер не поменятеся. И тем самым вы нарушете последовательность нумерации в этом году!

ну и потом, смотри момент присвения номера, присвоение ДАТЫ должно быть всегда ДО присвения номера

По ходу в клюшках номер автоматом присваивается при создании дока. И дата тоже автоматом рабочая дата.

Вся проблема - это переход на новый год и попытка юзеров рабоать задним числом.

нее.. рабочую дату они не трогают. файлы блокировок есть и в каталогах самих ползователей и в каталоге базы он тоже есть. выгнать всех я сейчас не могу.. потому как идет процесс выписки.. только если вечером гляну. чтобы посмотреть какие файлы создаются, при создании документа. юзвери задним числом пока ничего не вводили.. т.е. с этим вроде бы тоже не связано. может какие-то ключи специфические в настройках базы sql-ной?

2. запись в таблице выделения номеров (имя таблицы зависит от нумератора) подобных таблиц ненахожу.. =( у таблице доков есть поле ключ pk_dh42, но он вроде бы более нигде ни фигурирует.. отдельно от этой таблици.

позырь файл DDS

#=============================================================================== #==TABLE no 5      : ??????? ?????????? # Name    |Descr                         |SQLTableNam|RecordLock T=1SDNLOCK|??????? ??????????            |_1SDNLOCK  |           #-----Fields------- # Name                  |Descr               |Type|Length|Precision F=DNPREFIX              |Prefix Document No  |C   |28    |0         F=DOCNO                 |Document No         |C   |16    |0         #----Indexes------ # Name                           |Descr         |Unique|Indexed fields                                              |Type       I=PK__1SDNLOCK                   |Prefix+No     |1     |DNPREFIX,DOCNO                                              |1           #

вот содержимое этой таблички [URL=

содержимое таблички периодически подчищается...

2 Тихий омут: у тебя тоже 7.7. под sql крутится? Можешь скинуть свою версию bkend.dll?

При работе на базе MS SQL 2005 может возникнуть проблема с автонумерацией документов (при интерактивном создании нового документа номер присваивается некорректно), причём проблема эта воспроизводится не всегда. Чтобы обойти эту проблему, можно поместить в процедуру "ПриЗаписи" всех документов код, подобный следующему: докДок=СоздатьОбъект("Документ."+Вид);

значит не стоит семерку разворачивать в 2005м и в 2008м скуле. ТАк и сделаем ни за что....

2big: тоже уже подумал о подобном.. просто непонятно, почему такое произошло =( а так да, как вариант самому искать первый свободный номер.

phz

зря.

Связка 77 vs 2008 работает, не сказать что как часы, но вышеперечисленных проблем нет. Другие есть - этих нет :) Полезная ссылка, благодарю.

Я грешу еще на пропатченный bkend.dll может там что-то лишков пропатчели... но странно, что несколько документов с утра записали нормально и вот после 20-30 вылезло подобное.

2 Patrio_O_Muerte: а что за проблемы есть? и сколько человек копашатся в базе одновременно?

>С чем столкнулся: стоят очень маленькие приращения для увелечения размера базы и журнала >транзакций.После выставления приемлемых значений связка 1с+sql2005 работает хорошо У кого по сколько стоит? у самого стояло по 1мб приращение.. поставил по 10

200 мб, 30 человек (активных 10). Тормоза при открытии форм (тут правда пока до конца не ясно - sql виноват или сеть), поиске подчиненных документов (пофиксено - отчеты переписаны). И самое неприятное: ТИИ не может до конца выполнится - падает с ошибкой задвенности неуникальных индексов, изменение типа реквизита с "Документ.РасходнаяНакладная" на тип "Документ" - также до конца не доходит (падает с ошибкой), в общем насколько я понял - все что приводит к пересчету ссылок и перезаполнению таблицы dbo._1SCRDOC (таже самая очистка это таблицы) приводит к тому что база не восстанавливается. Как я понял это связано, с тем что 1С иначе чем sql высчитывает время документа и в случае если в пределах одной секунды записано несколько документов могут возникнуть вышеописанные или иные проблемы. Видимо нас спасало до сих пор только то, что почти все документы у нас пишутся с временем +1 секунда, а ошибка ссылалась как раз на документы записанные в пределах одной секунды.

правильный ответ на в . Также будет проблема с подчиненными документами. А вообще ставь "Секретный релиз 1С 7.7" - судя по отзывам получается самая стабильная свзяка с 2008/2005 скулем

Кстати, а перейти на 2000 сиквел - не вариант?

+1 поговаривают, что там типовая "структура подчиненности" ведет себя совершенно непредсказуемо...

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

Что за "Секретный релиз 1С 7.7" ? А есть уверенность, что станет лучше? просто в файловой конфигурации таких проблем не наблюдалось.. была засада с ростущими индексами (когда у товара много полей с сортировкой) но она проявлялась только при перекачке данных в конце года. когда выгрузка создает новые элементы справочника... а тут по сути на ровном месте. =( не ожидал..

основной замысел перехода на скул был - уменьшить тормоза при выполнении отчетов и не плодить баз каждый год. бо в файловой версии пара манагеров, запустивших отчет о движении (или подобное) за длительный период, просто подвешивали базу и выписка документов останавливалась. может кто-еще какие идеи подкинет?.. юзвери работают в терминале, т.е. данные крутятся в сессии на сервере.. мощи сервера достаточно. даже, как вариант пробывал делать виртуальный диск в памяти и сливать файловую базу на него - особого выйгрыша это по сути не дает.. если не работать только в монопольном режиме. =) -- основная работа - это постоянная выписка накладных/прием заявок (около 40 пользователей реально рабочих) на базу + отчеты манагеров о движении товаров (как основное) т.к. номенклатурный справочник около 50тыс позиций

Спасибо.

: такие проблемы, вообще-то, разруливаются выделением отдельной отчетной базы. оптимально - УРиБД с отчетной базой-только-приемником.

Типовые отчеты все равно придется переделывать. Ибо "в типовом виде" на сиквеле все подтормаживает... а так - работаем на 2000 с достаточно приличным объемом данных и количеством пользователей, проблем никаких нет, "секретных релизов не требуется"

штатное конечно лучшее

Прошлые года так и было. Еженочно базы копировались в отдельные каталоги и представлялись, как базы для отчетов.. и это хоть и помогало, но некоторым надо "по сейчас" или "ой я забыла в какой надо запускать".. вобщем не всегда =( типовые отчеты хотел переписать под 1с++, вроде как знакомый тоже пользуется, поможет если что. просто не ожидал подобной подставы от простой нумерации документов. =)

основная проблема сейчас, это даже не время выполнение отчетов, а тормоза создаваемые ими при создании новых документов.

Секретный релиз, это интересно, но надо тестировать.. а чтобы тестировать, надо хотябы чтобы что-то работало. =)

У нас за декабрь 89 тыс. доков. Тормоза проявились, но не "напрочь". Так что "родной 2000-й" вполне себе тянет...

это всех документов или каких-то конкретных? у меня получилось одних расходников в месяц около 20тыс.. ну даже в общем в месяц думаю не более 50-60тыс будет

Пляски с номером документа? Что-то еще всплыло?

отчеты можно и на прямых запросах написать...

: т.е. из-за того, что был выбран кривой способ реализации хорошей идеи - предпочли отказаться от самой идеи, нагородив себе трудностей, которые потом героически преодолеваете...

+: это к тому, что с урбд синхронизация в рамках локалки - хоть с десятиминутным нтервалом и без выхода всех отовсюду вполне себе решает задачу даже с такими требованиями, которые ты озвучил

Да нет никаких "плясок"....

я сдел, как смог. в свободное от работы время. покажи как правильно, переделаю.

: уже все сказал. см. последнее предложение + . причем чем чаще выполнять обмен - тем меньше порция и тем незаметнее для пользователей он выполняется.

Какой порт(ы) открыть в БМ, чтобы цеплять к SQL по сети? Надо заставить работать старые ОЛЕ приблуды.

мндяаа..

Уважаемый Cthulhu, я уже давно понял, что твои посты бывают очень содержательны и информационно-насыщены. Можешь не обременять себя терзанием кнопок, если не хочешь.. зачем же насиловать себя? ;-)

Ты реально монстер, читал это? Обрати внимание на SQL сервера для семерки:    Microsoft SQL Server 6.5,    Microsoft SQL Server 7.0,    Microsoft SQL Server 2000. Для любых других версий SQL требуется патчи, бубны и другие шаманство :)

Порт стандартный :) Он один, протоколов несколько ;)

+ да и этот порт можно поменять.

: можешь не обременять себя угадыванием чего я хочу, и уж тем паче указыванием (в той или иной форме) что мне следует делать или не делать. ибо даже в условиях, когда ответы по сути свидетельствую о том, что ты изначально решил задачу далеко не самым оптимальным способом (вследствие чего продолжаешь тут продолжать просить помощи в твоем героическом преодолении тобой же созданных трудностей) - сие вsглядит глупо и рисковано появлением новых ущемленных грыж на комплексе неполноценности.

всем спасибо подключилсо. =)

=) ладно. не указываю.