07.03.2016 17:34
KirillHome
 
Решил обновить БП 3.0 до актуального релиза.
Посмотрел - платформа стоит тоже старая, сама БП постоянно намекает "Вышла новая версия платформы..."
Обновил платформу с 8.3.6 на 8.3.7.1949, обновил конфигурацию.
Дай, думаю, запущу "Тестирование и исправление" - а то давно уже не запускал.
Запустил.
И получил на куче объектов сообщения типа:
Код:
Строковое поле переменной длины не должно завершаться пробелами. Строка обрезана справа
Почитал - да, это какое-то "милое" свойство платформы 8.3.7
Единственное вразумительное объяснение нашёл на Мисте
Цитата:
По ходу дела ни один из релизов 8.3.7 не умеет обрабатывать строки в запроса - валится SQL на Подстрока и Выразить как Строка. Пробовали 8.3.7.1759, 8.3.7.1790. Везде одна и та же ошибка.
Вывод (для меня) такой - пока конфигурация не будет просить в явном виде 8.3.7 - не использовать 8.3.7 (не смотря на то, что в 8.3.7 есть и приятные плюшки, в частности - можно сделать два "совмещённых" окна одного отчёта и их сравнивать глазами, не переключаясь между окнами).
Ну - или проверять релизы платформы на эту ошибку - Обновляем платформу, запускаем ТИИ, видим эту ошибку или нет.
08.03.2016 14:17
MWWRuza
 
Не, ну это в принципе, как я понимаю не ошибка, а просто "причесывание" БД. Что плохого, в том, что обрезаны пробелы справа? Была в поле БД строка типа "Бла-Бла ", а стала "Бла-Бла"... И что? Только база похудеет в объеме в итоге...
08.03.2016 20:31
KirillHome
 
Я сначала тоже так подумал, а потом...
В общем, не всегда я верю в простоту :)
08.03.2016 22:37
KirillHome
 
А вообще (как мне кажется) - это не причёсывание, а какой-то другой принцип работы со строками неограниченной длины.
Что-то сомневаюсь, что раньше хранили строки неограниченной длины с пробелами, не обрезая их справа.

Более того, на клерке пишут:

Цитата:
1С:Предприятие 8.3 (8.3.7.1759)
Бухгалтерия предприятия, редакция 3.0 (3.0.42.85)
Здравствуйте!
Выполнил тестирование и исправление базы. Появилась куча предупреждений такого вида:
Проверка логической целостности. Справочник.ПерепискаСКонтролирующимиОрганами.Рекви зит.Содержание о доведении информации
ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0
Строковое поле переменной длины не должно завершаться пробелами.
Одно и то же только в разных документах. Исправление обрезает значение поля. При повторном тестировании предупреждения не появляются.
После создания новых документов в базе и повторного тестирования появляются аналогичные ошибки во вновь созданных документах.
(выделение - моё)

Так что пока - ну на фиг!
09.03.2016 10:21
MWWRuza
 
Ну почему... Могли и хранить. Чем пробел не символ? Если из конфы, при записи значения в поле неограниченной длины, не обрезать пробелы СокрЛП(КакоеТоЗначение), где КакоеТоЗначение - например наименование из справочника, имеющее фиксированную длину, например 50, то при наименовании "Водка Столичная 0.5", запишется 19 символов самого наименования, и 31 пробел справа... Я в своих конфах в таких случаях всегда СокрЛП() применяю, но, видимо в типовых их авторы иногда благополучно об этом забывают... Видимо в релизе 8.3.7 решили это делать на уровне платформы, но, как всегда не довели до конца - в тестировании и исправлении обрезают пробелы, а при записи новых объектов, по прежнему надеются на то, что разработчики конфигураций будут сами обрезать пробелы... Надеюсь, что в следующем релизе доделают, раз начали. Я бы сильно не обращал внимание на это, всю жизнь работало, и хранились там пробелы.... И проблем небыло, а сейчас просто стали в тестировании и исправлении это замечать и исправлять.
09.03.2016 10:47
student
 
Цитата:
KirillHome А вообще (как мне кажется) - это не причёсывание, а какой-то другой принцип работы со строками неограниченной длины.
скорее всего просто переход в таблице скуля от одного типа данных к другому :)
===
если поле имеет признак NOT NULL, то тип VARCHAR занимает в таблице места столько, сколько значащих байт в строке (последние пробелы отрезаются), а CHAR занимает столько - сколько задано и добивает при необходимости пробелами. Если поле имеет признак NULL, то тип CHAR и VARCHAR ведут себя одинаково.
===
источник уже и не упомню :(

вероятнее всего с хранением юникода связано - т.е. сделан переход в скуле на тип NVARCHAR, правда Microsoft утверждает, что доступ к полю CHAR идет быстрее, но на сколько (или во сколько) неизвестно :)
09.03.2016 11:22
KirillHome
 
Подумал - а вдруг это связано с подготовкой перехода на новый формат файла базы данных.
Нет, на пишут, что

Цитата:
Файл базы данных имеет несколько версий внутреннего формата:

1. Версия 8.2.14 – имеет размер внутренней страницы файла базы данных равный 4096 байт.

2. Версия 8.3.8 – размер внутренней страницы файла базы данных может принимать несколько значений: 4096, 8192, 16384, 32768 и 65536 байт. Кроме того, формат 8.3.8 обеспечивает более оптимальный формат хранения некоторых внутренних данных.

Система «1С:Предприятие» версии 8.3.8 и старше обеспечивает функционирование с файлом 1Cv8.1CD любого формата без дополнительных действий. Система «1С:Предприятие» версии 8.3.7 и младше обеспечивает функционирование с файлом 1Cv8.1CD только версии 8.2.14. Преобразование между двумя форматами возможно либо с помощью операции выгрузки/загрузки данных информационной базы в файл .dt, либо с помощью специальной утилиты cnvdbfl.
21.04.2016 23:50
KirillHome
 
Посмотрел сегодня на работу платформы 8.3.8.1652 (если не ошибаюсь - первая версия, пошедшая "в работу", а не в "версия для тестирования").

Как минимум: описанная в начале ошибка - отсутствует.
Часовой пояс GMT +3, время: 12:13.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.