Как выявить незакрытые регистры?

Форум Учет и отчетность Складской учет и логистика (WMS)

1С:Производство+Услуги+Бухгалтерия Оперативный учет 7.7 1С:Торговля и склад 7.7

1. Ikhalek 12.07.12 14:00 Сейчас в теме

Доброго времени суток.

Ужасно распухла база ТИС 5ГБ и соответственно так же ужасно тормозит. Подозреваю, что могут быть незакрытые регистры. Подскажите пожалуйтса техническому специалисту без бухгалтерского образования как их можно выявить, и как с ними бороться.

По теме из базы знаний

Переход с УПП на ERP с сохранением документов. Фантастика или реальность?

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. Ёпрст 1067 12.07.12 14:06 Сейчас в теме

проверить размер одноименных табличек регистров , там где
RG > RA регистр не закрыт.

+ избавиться от нулевых значениях ресурсов в итогах регистров и сжать таблички в первую очередь.

6. Ikhalek 12.07.12 17:52 Сейчас в теме

(2) Ёпрст, RG328.DBF = 2ГБ
RG328 = 1,5ГБ
RG405.DBF = 446МБ
RG405 = 325МБ
RA328.DBF = 328МБ
RA405.DBF = 100МБ

А как это сделать поподробней объясните пожалуйста нубу (избавиться от нулевых значений ресурсов итогов и сжать таблички)?

А файлы без расширения DBF это что?

3. Joker_Ann 12.07.12 15:40 Сейчас в теме

А какой у вас документооборот? Может пора делать свертку базу?

4. Ikhalek 12.07.12 16:25 Сейчас в теме

(3) Joker_Ann, Около 100 документов в день. Документы есть с декабря 2009 года. Хочу сделать свертку, только перед этим закрыть регистры и сделать тестирование и исправление. Я движусь в правильном направлении?

5. Ёпрст 1067 12.07.12 17:49 Сейчас в теме

(4)не совсем

7. Ёпрст 1067 12.07.12 18:18 Сейчас в теме

RG328.DBF = 2ГБ
RG328 = 1,5ГБ

1.Это как ?
2.Это п..ц

10. Ikhalek 12.07.12 18:43 Сейчас в теме

(7) Ёпрст, Согласен, ощущаю пипец при работе. А как с этим кошмаром бороться? Регистры закрывать? Или тут что-то посерьезней надо?

11. Ёпрст 1067 13.07.12 09:47 Сейчас в теме

(10) для начала правильно запостить имена регистров и их размеры сюда.

14. Ikhalek 13.07.12 10:21 Сейчас в теме

(11) Ёпрст, Я размеры смотрел в папке с базой с помощью експлорера? Я не те размеры указал?

15. Ёпрст 1067 13.07.12 10:26 Сейчас в теме

(14) см. (6):

RG328.DBF = 2ГБ
RG328 = 1,5ГБ

RG405.DBF = 446МБ
RG405 = 325МБ

Это что ?

Что за 2 одноименных файла ?!

16. Strawberry 13.07.12 10:33 Сейчас в теме

(15) Ёпрст, как что
DBF и CDX
просто cdx - это зарегистрированное расширение вот оно и не показывается :)

17. Ёпрст 1067 13.07.12 10:40 Сейчас в теме

(16) я не верю в 2-х гиговый индексный файл

42. frlancer 28.12.13 04:53 Сейчас в теме

Добрый вечер. Таких тем уже много и все советуют одно и тоже. Почитал, следую инструкциям.
По факту: ТиС 7.7.929, dbf, дописанная. Размер базы 1.635 ГБ.
До этого очень долго открывался период. В этом месяце, не открылся вовсе. Виснет на пересчете итогов.
Документов с пустой датой нет. Смотрел в журнале. Выгрузил в sql, смотрел там. К слову на sql'е открытие периода проходит достаточно оперативно. Минут 15, но назад не загружается, виснет. Клиент на sql переходить не хочет.

Смотрю измерения регистров: РезервыТМЦ и ОстаткиТМЦ, там деятели напилили дополнительных измерений: длина, ширина, толщина - строка(10) и "Примечания" - строка(100). Отбор итогов по этим реквизитам не стоит.
В Примечания пишутся реально примечания из документов. Я не силен в методологии, но разве так закроется регистр?
Размер соответствующих таблиц:
ОстаткиТМЦ:
RG405.DBF - 323мб, RA405.DBF - 12.6мб
RG405.CDX - 167мб, RA405.CDX - 0.5мб

РезервыТМЦ:
RG4480.DBF - 126мб, RA4480.DBF - 9мб
RG4480.CDX - 78мб, RA4480.CDX - 0.5мб

Возможно ли что пересчет итогов не происходит из за этих измерений? Какие варианты решения этой проблемы?
ТиИ не проходит, виснет опять же на пересчете итогов.

8. Ёпрст 1067 12.07.12 18:22 Сейчас в теме

Интересно, как вы при размере табличек итогов >1 гига отчеты глядели (если конечно решений от hogik не стоит) и как у вас там период открывался..?

9. hogik 444 12.07.12 18:28 Сейчас в теме

(8)
RG328.DBF = 2ГБ???

12. l_men 16 13.07.12 09:58 Сейчас в теме

Что касательно семерки то в папке с базой есть файл 1cv7.DD - это файл описания метаданных там нужно найти RG328 - и будет понятно какой регистр так распух.

13. Ikhalek 13.07.12 10:20 Сейчас в теме

(12) l_men, Нашел, RG328 - ПартииНаличие, RG405 - ОстаткиТМЦ.

18. l_men 16 13.07.12 10:47 Сейчас в теме

(13) Ikhalek, Вот он возможно и не закрывается, проверяется просто, нужно построить отчет по партиям в разрезе всех аналитик, и посмотреть. Если все нормально, т.е. все измерения регистра закрываются, то тогда поможет свертка базы, кстать насколько я помню обрабтка была встроена в торговлю, но лучше все равно попробовать на копии.

19. Ёпрст 1067 13.07.12 10:50 Сейчас в теме

(18) не поможет

20. l_men 16 13.07.12 10:56 Сейчас в теме

(19) Ёпрст, Почему?

21. Ёпрст 1067 13.07.12 11:03 Сейчас в теме

(20) потому, что не свернёт, это раз.
С таким незакрытым регистром придётся убирать лишнюю аналитику в итогах и чем то жертвовать, это два.

Автор на такое не способен, это три.

22. Ёпрст 1067 13.07.12 11:05 Сейчас в теме

Если на Партии можное еще забить, кастрировав аналитику по партии и в вводе оснтанков повесить всё на 1 партию, а вот что делать с ОстаткамиТМЦ - хз..
Не ясно еще, по какой аналитике у него так регистр распух.

Если автор не Рома Каблуков, конечно, но, мот понавтыкал своих измерений в регистр ?

24. Ikhalek 13.07.12 11:18 Сейчас в теме

(22) Ёпрст, Вот кусок файла 1cv7.DD с измерениями этих регистров.

#==TABLE no 162 : Регистр ПартииНаличие
# Name |Descr |Type[A/S/U]|DBTableName|ReUsable
T=RG328 |Регистр ПартииНаличие |A |RG328 |1
#-----Fields-------
# Name |Descr |Type|Length|Precision
F=PERIOD |Period Registr |D |8 |0
F=SP4061 |(P)Фирма |C |9 |0
F=SP330 |(P)МОЛ |C |9 |0
F=SP331 |(P)Номенклатура |C |9 |0
F=SP340 |(P)СтатусПартии |C |9 |0
F=SP341 |(P)Партия |C |9 |0
F=SP1554 |(P)ДатаПартии |D |8 |0
F=SP7404 |(P)ЦенаПрод |N |16 |2
F=SP342 |(P)Количество |N |16 |5
F=SP421 |(P)СуммаУпр |N |16 |2
F=SP343 |(P)СуммаРуб |N |16 |2
F=SP344 |(P)СуммаБезНДС |N |16 |2
F=SP8062 |(P)СуммаПлат |N |16 |2
#----Indexes------
# Name |Descr |Unique|Indexed fields |DBName
I=PROP |PERIOD+PROP |0 |PERIOD,SP4061,SP330,SP331,SP340,SP341,SP1554,SP7404 |PROP
I=VIA331 |VIA331 |0 |PERIOD,SP331 |VIA331
#
#===============================================================================
#==TABLE no 163 : Регистр (Дв.) ПартииНаличие
# Name |Descr |Type[A/S/U]|DBTableName|ReUsable
T=RA328 |Регистр (Дв.) ПартииНаличие |A |RA328 |1
#-----Fields-------
# Name |Descr |Type|Length|Precision
F=IDDOC |ID Document's |C |9 |0
F=LINENO |LineNo |N |4 |0
F=ACTNO |Action No |N |6 |0
F=DEBKRED |Flag Debet/Kredit |N |1 |0
F=SP4061 |(P)Фирма |C |9 |0
F=SP330 |(P)МОЛ |C |9 |0
F=SP331 |(P)Номенклатура |C |9 |0
F=SP340 |(P)СтатусПартии |C |9 |0
F=SP341 |(P)Партия |C |9 |0
F=SP1554 |(P)ДатаПартии |D |8 |0
F=SP7404 |(P)ЦенаПрод |N |16 |2
F=SP342 |(P)Количество |N |16 |5
F=SP421 |(P)СуммаУпр |N |16 |2
F=SP343 |(P)СуммаРуб |N |16 |2
F=SP344 |(P)СуммаБезНДС |N |16 |2
F=SP8062 |(P)СуммаПлат |N |16 |2
F=SP347 |(P)КодОперации |C |9 |0
F=SP6818 |(P)ПродСтоимость |N |19 |2
F=SP7768 |(P)Выручка |N |16 |2
#----Indexes------
# Name |Descr |Unique|Indexed fields |DBName
I=IDLINE |of IDDOC+LineN|0 |IDDOC,LINENO,ACTNO |IDLINE
#

26. l_men 16 13.07.12 11:26 Сейчас в теме

(22) Ёпрст, Ну для начала надо убедиться, что он действительно "распух" из-за незакрывающейся аналитики, а если и да, то тогда нужно менять движения документов, что бы закрвались регистры и перепроводить все документы.

29. Ёпрст 1067 13.07.12 11:33 Сейчас в теме

(26) тебе размер файла итогов и движений ни о чем не говорит уже ?
:))

23. Ikhalek 13.07.12 11:12 Сейчас в теме

А этой сверткой тоже не свернет?

25. Ёпрст 1067 13.07.12 11:26 Сейчас в теме

(23) нет.
Тебе при любой свёртке нужно будет "избавляться" от лишних измерений.

покажи структуру RG405

ЗЫ: торговля в Розницу ?
пару фирм еще поди ?

32. Ikhalek 13.07.12 13:02 Сейчас в теме

(25) Ёпрст, Ага, торговля в розницу.

Вот структура RG405

#==TABLE no 160 : Регистр ОстаткиТМЦ
# Name |Descr |Type[A/S/U]|DBTableName|ReUsable
T=RG405 |Регистр ОстаткиТМЦ |A |RG405 |1
#-----Fields-------
# Name |Descr |Type|Length|Precision
F=PERIOD |Period Registr |D |8 |0
F=SP4062 |(P)Фирма |C |9 |0
F=SP408 |(P)Номенклатура |C |9 |0
F=SP418 |(P)Склад |C |9 |0
F=SP3117 |(P)ЦенаПрод |N |16 |2
F=SP411 |(P)Количество |N |16 |5
#----Indexes------
# Name |Descr |Unique|Indexed fields |DBName
I=PROP |PERIOD+PROP |0 |PERIOD,SP4062,SP408,SP418,SP3117 |PROP
I=VIA408 |VIA408 |0 |PERIOD,SP408 |VIA408
#
#===============================================================================
#==TABLE no 161 : Регистр (Дв.) ОстаткиТМЦ
# Name |Descr |Type[A/S/U]|DBTableName|ReUsable
T=RA405 |Регистр (Дв.) ОстаткиТМЦ |A |RA405 |1
#-----Fields-------
# Name |Descr |Type|Length|Precision
F=IDDOC |ID Document's |C |9 |0
F=LINENO |LineNo |N |4 |0
F=ACTNO |Action No |N |6 |0
F=DEBKRED |Flag Debet/Kredit |N |1 |0
F=SP4062 |(P)Фирма |C |9 |0
F=SP408 |(P)Номенклатура |C |9 |0
F=SP418 |(P)Склад |C |9 |0
F=SP3117 |(P)ЦенаПрод |N |16 |2
F=SP411 |(P)Количество |N |16 |5
F=SP420 |(P)Внутреннее |N |2 |0
#----Indexes------
# Name |Descr |Unique|Indexed fields |DBName
I=IDLINE |of IDDOC+LineN|0 |IDDOC,LINENO,ACTNO

27. stu1112 9 13.07.12 11:28 Сейчас в теме

Поможет только свертка, данны иначе, через некоторое время база у Вас просто перестанет работать (документы будут по часу проводится) стандартаная свертка работает очень долго (несколько дней). Лично я в такой ситуации удалял физически dbf файлы с регистрами и документами и формировал документы ввода остатков

28. l_men 16 13.07.12 11:31 Сейчас в теме

(27) stu1112, А что делалось перед тем как удалить файл? Можно методику описать подробнее?

38. stu1112 9 13.07.12 15:22 Сейчас в теме

(28) l_men, Сделать , копию базы, удалить базы
Pause
del New_Stru
del Syslog
del *.cdx
del *.lst
del 1cv7srct.st
del dt*.*
del dh*.*
del 1sjourn.dbf
del 1scrdoc.dbf
del 1sdnlock.dbf
del 1sstream.dbf
del rg*.*
del ra*.*
del 1SOPER.dbf
del 1SENTRY.dbf
del 1SBKTTLC.dbf
del 1SBKTTL.dbf
del 1SACCSEL.dbf
del 1SSBSEL.dbf
del 1supdts.dbf
del 1sdwnlds.dbf
del 1sdbset.dbf
останутся только справочники
Затем запустить обрабоку переноса остатков в новую базу (поищи на инфостарте какая подойдет)
И при необходимости перенести и перепровести документы за нужный период
А за 3 года при движении 100 док в день база раздуется и без косяков

39. epf 14.07.12 14:21 Сейчас в теме

(38) Свертку то он сделает. Но проблема не закрытх регисров ведь останется?

41. Ikhalek 17.07.12 11:14 Сейчас в теме

(38) stu1112, А эти файлы и каталоги восстановятся после переноса остатков? Или понадобится делать ТиИ?

44. CheBurator 2725 30.12.13 03:15 Сейчас в теме

(38) > 100 док в день
- такой объем - это вообще какой-то детский лепет, а не большое количество документов. хотя, конечно, если в каждом документе строг по 5-8 тысяч - ну тогданаверное да.. но не думаю что такие проблемы...

45. frlancer 30.12.13 13:57 Сейчас в теме

(44) А относительно моей ситуации, есть какие то мысли?
(43) К слову разобрался зачем "Примечания" в регистре. У них партия это характеристики + "Примечания". А "Примечания", это просто текст пользователем указанный. Опять же не уверен, что это правильно.

46. CheBurator 2725 31.12.13 02:12 Сейчас в теме

(45) а какие мысли?
стандартные - их вверху все описали...
разобраться, вычистить, при необходимости - свернуть, похерив несущественное/кривое.

30. Ёпрст 1067 13.07.12 11:34 Сейчас в теме

Если что, файло итогов должно быть в разы меньше файла движений.
А не наоборот, как у автора, у которого "непустые незакрытые" промежуточные итоги тащатся из периода в период

31. l_men 16 13.07.12 11:38 Сейчас в теме

(30) Ёпрст, Тогда диагноз один, искать какой документ при проведении "косячит" с итогами исправлять и перепроводить, либо исправлять и переносить остатки в новую базу. Мне кажется быстрее будет исправлять и переносить остатки в новую базу.

33. l_men 16 13.07.12 13:14 Сейчас в теме

Теперь нужно проанализировать движения по данному регистру, у него три измерения Фирма, Номенклатура, Склад. Соответственно анализировать нужно движения по каждому из них, т.е. на какую фирму/склад/номенклатуру поступает и с какой(го) фирмы/склада/номенклатуры делается реализация.

34. Ikhalek 13.07.12 13:34 Сейчас в теме

(33) l_men, Понял, а как провести такой анализ, использовать специальную обработку или есть встроенное решение? Пардоньте если совсем туплю, я месяц назад познакомился с 1с.

35. Ёпрст 1067 13.07.12 13:36 Сейчас в теме

(34) Для начала, выгрузитьИтоги в ТЗ и посмотреть, что там..
У тебя 90% "плывет" аналитика по ЦенаПрод

ЗЫ: воспользуйся regprint.ert с диска ИТС

36. Ikhalek 13.07.12 14:03 Сейчас в теме

Спасибо, буду смотреть.

37. Ёпрст 1067 13.07.12 14:09 Сейчас в теме

(36) потом уже думай, как "свернуть" или исправить проведение документов.
По-уму, нужно смотреть, как вели учет, на какой склад поступал товар, как перемещали в розницу, как реализовали и т.д..
Т.е смотреть движения документов.
А "кастрировать" успеется, иначе в после кастрации база опять придёт в "негодность" в скором времени.

40. alexey_1c 16.07.12 10:04 Сейчас в теме

переходите на 8-ку

43. frlancer 28.12.13 14:43 Сейчас в теме

Я так понимаю, предыдущие разработчики сделали механизм ведения учета в разрезе характеристик. Вот только не понятно зачем "Примечания" в регистр писать. И почему остальные характеристики строковые?

47. CheBurator 2725 31.12.13 02:12 Сейчас в теме

Вопрос в том, что работы по вычистке/уборке дерьма на порядок и более трудозатратнее разбрасывания дерьма..

50. AndKovalchuk 196 01.01.14 10:54 Сейчас в теме

(47) CheBurator,

Вопрос в том, что работы по вычистке/уборке дерьма на порядок и более трудозатратнее разбрасывания дерьма..

Можно тупо удалить несущественные измерения по регистру ( к примеру характеристики). Сохранить конфигурации и соответственно реструктуризовать базу. А затем вернуть измерения обратно.

51. frlancer 02.01.14 19:06 Сейчас в теме

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

48. frlancer 31.12.13 19:24 Сейчас в теме

Всем спасибо, буду стараться. С наступающим Новым Годом.

49. AndKovalchuk 196 01.01.14 10:50 Сейчас в теме

На диске ИТС есть универсальные отчеты для 7.7 , и там среди прочего есть "Универсальный отчет по регистру". Очень удобная штука, чтобы посмотреть где-чего не закрыто.

52. AndKovalchuk 196 02.01.14 21:47 Сейчас в теме

Это идея. Вот только,я не очень понимаю, как сформируются записи в регистрах итогов, если не делать пересчет итогов. Получается что у меня итоги будут рассчитаны без дополнительных измерений. И когда я их добавлю, то данных по этим измерениям не будет вообще?
Как тогда будет отрабатывать механизм партионного учета, в котором задействованы эти измерения?

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

53. frlancer 03.01.14 18:15 Сейчас в теме

(52)Ну у них немного не так. У них один товар характеризуется измерениями: Номенклатура, характеристики(высота,ширина,длина) и Примечания(строка100 из документа, сюда пишут пользователи).
Получается что два товара у которых одинаковые Номенклатура и Характеристики, но разные примечания, то в таблице итогов они будут отдельными строчками.
Следовательно если я буду делать пересчет итогов без измерения "Примечания", то эти строчки "схлопнуться". Что не правильно, по моему.
Как мне быть в таком случае?

54. AndKovalchuk 196 03.01.14 20:53 Сейчас в теме

Интересно, а когда они отгружают товар, они тоже что-то пишут ручками, или выбирают из списка?

55. frlancer 03.01.14 22:21 Сейчас в теме

(54) Выбирают. У них реализована своя форма подбора в которой выводятся товары с характеристиками и примечанием. Они выбирают определенный товар, по нему происходит расход.

56. frlancer 06.01.14 08:28 Сейчас в теме

Я так понимаю механизм пересчета итогов "скрыт" внутри платформы? Можно в процессе пересчета итогов как то посмотреть отладчиком или сторонним ПО, что там происходит?
Может в моем случае, просто в строковых измерениях какие то символы служебные используются или еще что то подобное.

57. AndKovalchuk 196 06.01.14 21:12 Сейчас в теме

Я так понимаю механизм пересчета итогов "скрыт" внутри платформы?

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

58. frlancer 06.01.14 22:04 Сейчас в теме

(57) Вы про отрицательные остатки, сейчас? Просмотрел я отчет по итогам, нет там ничего сверхъестественного. По крайней мере на первый взгляд не бросается. Очень много дублей номенклатуры. Но опять же это из за того что там заполняют измерения "Примечания". Вот и получается что одна номенклатура с разными "Примечаниями" попадает в разные строки таблицы итогов. Но эти остатки переходящие, они буквально месяц тянутся. Так кажется все закрывается.
Не пойму тогда почему зависает пересчет регистров.

59. AndKovalchuk 196 07.01.14 12:55 Сейчас в теме

Можно попробовать сделать примечание не строкой, а справочником. Тогда и места поменьше понадобится и пересчет скорее всего побыстрее заработает. Потому что, в итогах будет храниться только ссылка на справочник.

60. frlancer 07.01.14 21:33 Сейчас в теме

(59) Я про этот вариант думал. Только вот заказчик говорит что так не подходит. Ибо у них эти партии товара формируются с учетом примечания и ни кто там не будет забивать инфой справочник. Им быстрее и удобнее просто строку ввести и все.

Сейчас вот думаю написать обработку на проверку служебных символов(с кодами <32) в этих строковых измерениях. Просто судя по примечаниям, они копированием эти строки вставляют. Откуда не знаю. Потом попробую вместо строк подставить какие то числовые идентификаторы и открыть период.

Какие мысли относительно служебных символов, может из за этого быть проблемы?

64. ivsher 08.01.14 10:57 Сейчас в теме

(60) day_light, как я понял из предыдущих постов у вас первичный ключ для таблицы итогов регистра имеет длину более 120 символов. По умолчанию в ключ входит дата, и все измерения регистра, что мы имеем в итоге: prtiod 8, Номенклатура 9, характеристика ? (непонял сколько символов, предположим 9, если это ссылка на справочник) и самое печальное это примечание 100 в итоге явно больше 120 символов. 1с с ключами больше 120 символов, в формате дбФ, правильно работать не умеет. Выход пока вижу один. Проанализируйте примечания, найдите самое длинное и сократите длину поля до этого значения. Ну или переход на скуль там таких проблем с пересчетом нет. Ну как вариант, если клиенты против sql, выгрузить в скуль, пересчитать итоги,загрузить назад в дбф :). А если решать проблему кардинально, то необходимо создать справочник примечаний и его уже использовать в регистре, ключ сразу же сократиться на 91 символ.

65. frlancer 08.01.14 11:11 Сейчас в теме

(64) Спасибо вам за ответ. Я вот не знал про ограничения длины первичного ключа. Теперь мне понятнее стало. Вы правы получается больше 120 символов. Под "характеристиками" я имел ввиду 3 реквизита типа строка, длинной 10.
Так что там однозначно больше 120ти символов :)
Теперь понятно почему в sql'е нормально пересчет проходит. Буду смотреть в сторону укорачивания "Примечания".

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

66. frlancer 08.01.14 17:46 Сейчас в теме

(64) А есть какие то ссылки на источники относительно ограничений первичного ключа в dbf версии на 120 символов?
Я просто искал. Нашел, только что в принципе первичный ключ не может превышать 900 байт. Да и то там данные автоматически урезаются.
Интересно почитать, для собственного развития.

68. ivsher 09.01.14 09:56 Сейчас в теме

(66) day_light, ну обычно с этой проблемой люди сталкиваются при добавлении реквизитов в справочник. Т.е. имеется некий справочник в котором на нескольких реквизитах в конфигураторе стоит признак "сортировка". Естественно такой реквизит добавляется в ключ. Ну и вот было замечено, что если общая длинна ключа приближается к отметке 120 символов то возникают проблемы с добавлением реквизита в такой справочник. Ссылок на эту проблему в интернете хватает. У вас ситуация аналогичная, только ключ не в таблице справочников, а в таблице итогов регистра, но суть проблемы от этого не меняется. Вот для примера первая попавшаяся ссылка http://forum.infostart.ru/forum9/topic36308/

67. M.Flint 09.01.14 06:12 Сейчас в теме

(60) day_light, Предлагаю все-таки перейти на справочник. В документе можно оставить ввод примечания строкой для удобства пользователей, а при проведении документа уже подставлять ссылку на справочник. Искать по наименованию и программно добавлять новые записи в справочник при необходимости.

69. frlancer 09.01.14 10:57 Сейчас в теме

(67) Поиск по наименованию, не считаю правильным. Но совет дельный. К сожалению, заказчика такой вариант не устраивает.
(68) Вчера уже нашел подобную информацию про ограничение в 240байт. Что в формате Юникода и равно 120ти символам, если не ошибаюсь. Спасибо вам ivsher, за помощь. Ваш совет оказался ключевым для решения моей проблемы.

В данный момент идет разговор о переходе на sql. Для себя я пробую урезать реквизит до 30ти символов и посмотреть, действительно ли это поможет.

Про результаты отпишусь.

61. AndKovalchuk 196 07.01.14 22:19 Сейчас в теме

Возможно. Трудно сказать как работает штатная сортировка строк с такими символами.

62. frlancer 08.01.14 04:09 Сейчас в теме

Проверил, нет там ничего.

63. frlancer 08.01.14 05:54 Сейчас в теме

Посмотрел в sql'е обработкой на наличия записей с 0ми значениями. Нет и таких. Не понимаю уже ничего. Что ж тут еще быть то может.

70. frlancer 10.01.14 02:54 Сейчас в теме

На данный момент не удалось узнать что то определенное.
Моя задача решена. Заказчика перевели на sql.

Относительно ограничения в 120 символов, так и не смог корректно уменьшить длину реквизита. В dbf реструктуризация вылетела с ошибкой именно на этот реквизит. В sql все прошло нормально, но при последующей выгрузке-загрузке в dbf, так ничего и не получилось. Загрузка длилась 12 часов. Не выдержал.

При этом в sql все работает нормально. Загрузка 3 минуты. Открытие периода за секунды. Пока на этом свои изыскания заканчиваю. Всем большое спасибо за помощь.

Оставьте свое сообщение

E-mail: