SASGIS - SAS.Планета
View Issue Details
0002897SAS.Планета[All Projects] Багpublic07-11-2015 21:0609-05-2017 09:42
sheavy 
zed 
normalminorhave not tried
closednot fixable 
Windows7Professional
151111 
 
0002897: Пропадают некоторые метки после импорта в MS SQL и рестарта программы
После импорта программа ведет себя безупречно. Категории открываются быстро, ничего не пропадает. Но после рестарта больше половина меток почему-то не показывается и программа начинает тормозить как будто не может получить чей-то отклик. Метки пропадают каждый раз одни и те же.
смотрите пример меток во вложенных файлах
БД, метки
? markshide.sml (248,560) 07-11-2015 21:06
http://www.sasgis.org/mantis/file_download.php?file_id=1968&type=bug
? Categorymarkshide.sml (1,600) 07-11-2015 21:07
http://www.sasgis.org/mantis/file_download.php?file_id=1969&type=bug
Issue History
07-11-2015 21:06sheavyNew Issue
07-11-2015 21:06sheavyFile Added: markshide.sml
07-11-2015 21:07sheavyFile Added: Categorymarkshide.sml
07-11-2015 21:08sheavyTag Attached: БД
07-11-2015 21:08sheavyTag Attached: метки
08-11-2015 15:26zedNote Added: 0016755
08-11-2015 15:27zedStatusnew => confirmed
09-11-2015 11:20vdemidovAssigned To => zed
09-11-2015 11:20vdemidovStatusconfirmed => assigned
09-11-2015 11:20vdemidovTarget Version => 151111
10-11-2015 06:26zedNote Added: 0016772
10-11-2015 06:26zedStatusassigned => feedback
10-11-2015 10:57zedNote Added: 0016773
10-11-2015 10:58zedTarget Version151111 => 191221
11-11-2015 11:40sheavyNote Added: 0016778
11-11-2015 11:40sheavyStatusfeedback => assigned
11-11-2015 11:40sheavyNote Edited: 0016778bug_revision_view_page.php?bugnote_id=16778#r6779
11-11-2015 11:42sheavyNote Added: 0016779
11-11-2015 18:36zedNote Added: 0016785
11-11-2015 18:37zedNote Added: 0016786
11-11-2015 18:37zedNote Edited: 0016785bug_revision_view_page.php?bugnote_id=16785#r6781
15-11-2015 14:52sheavyNote Added: 0016834
15-11-2015 14:57zedNote Added: 0016835
15-11-2015 15:06sheavyNote Added: 0016836
15-11-2015 15:07sheavyNote Edited: 0016836bug_revision_view_page.php?bugnote_id=16836#r6802
18-11-2015 09:58vdemidovProduct Version.Nightly => 151111
18-11-2015 09:58vdemidovTarget Version191221 => 160606
11-05-2016 08:16zedStatusassigned => closed
11-05-2016 08:16zedResolutionopen => not fixable
13-05-2016 07:20vdemidovTarget Version160606 =>
09-05-2017 09:42zedNote Added: 0017941

Notes
(0016755)
zed   
08-11-2015 15:26   
Если в описании метки текста более 35 (?) символов, в логах идут сообщения:

> [01004] [Microsoft][SQL Server Native Client 10.0]String data, right truncation (0)
> [07009] [Microsoft][SQL Server Native Client 10.0]Invalid Descriptor Index (0)

и из базы не удаётся прочитать эти метки.

MySQL при этом работает нормально.

По традиции, ждём отклика от разработчиков mORMot: http://synopse.info/forum/viewtopic.php?id=3002

Баги, конечно, эпические и создаётся чувство, что этой обёрткой в mORMot никто не пользуется...
(0016772)
zed   
10-11-2015 06:26   
Мне тут добрые люди подсказали, что проблему можно обойти, заменив текстовые поля в таблицах с nvarchar(max) на nvarchar(2000), к примеру.

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

Проверьте, как оно и что будет, если задать не 2000 а пару миллионов, например, и сохранить Войну и Мир в описание метки :)

И, кстати, протестируйте сохранение тяжёлых геометрий - запишите в базу gps трек в несколько десятков мегабайт? Может там и с этим есть проблемы. MySQL и PostgreSQL я тестировал на таких больших данных, справляются.

Если нету своих тяжёлых треков, то их можно взять на www.gpslib.ru, к примеру, или ещё где.
(0016773)
zed   
10-11-2015 10:57   
Есть ещё вариант использовать OLEDB драйвер вместо ODBC. В тестах работает без необходимости что-либо изменять в таблицах. Возможно, и бага 0002886 вылечится. В ближайшее время прикручу.
(0016778)
sheavy   
11-11-2015 11:40   
Относительно заработало, ура!!! Спасибо тем добрым людям, что подсказали! )

Пересоздал таблицу с действительно максимальными значениями для varbinary - 8000 и nvarchar - 4000.
Таким образом, проблема ушла, но сохранить Войну и Мир в описание метки все равно не получится пока.

Сохранение тяжёлых геометрий: проблема бага 0002886 не вылечилась из-за ограничения в 8000

С треками пока не тестировал, но, по-видимому, будет такая же ситуация.

(0016779)
sheavy   
11-11-2015 11:42   
OLEDB тоже будет интересно протестировать.
(0016785)
zed   
11-11-2015 18:36   
(edited on: 11-11-2015 18:37)
Мда, с OleDB тоже проблемы - оказывается оно наши блобы (геометрию меток) не может нормально сохранять. Ошибок чтения/записи не возникает, но из БД возвращаются (или сохраняются) обрезки блобов. Так что, куда ни кинь, а MS SQL работать совсем не хочет.

(0016786)
zed   
11-11-2015 18:37   
> проблема бага 0002886 не вылечилась из-за ограничения в 8000
Там надо пробовать менять используемый драйвер в настройках. Я всё ещё жду, когда вы это протестируете.
(0016834)
sheavy   
15-11-2015 14:52   
Извиняюсь за задержку - болезнь сразила ). У меня вопрос - никто не пробовал написать bug report в Microsoft? Это вполне нормальная европейская практика. Если не писали, я мог бы написать.

еще по ходу вопрос: я правильно понимаю, что схема dbo жестко зашита в коде? Это обязательно? если убрать dbo из кода, можно было бы действительно использовать - указывать их в строке соединения, например.
Это давало бы некоторую гибкость - не зря ведь их все-таки придумали.
(0016835)
zed   
15-11-2015 14:57   
>bug report в Microsoft
А есть уверенность, что это баг Microsoft а не врапера над ODBC/OleDB драйвером?

>что схема dbo жестко зашита в коде
Зашита, но не в коде SAS, а в коде используемого фреймворка. Убрать не представляется возможным.
(0016836)
sheavy   
15-11-2015 15:06   
(edited on: 15-11-2015 15:07)
Как можно было бы использовать схемы: например, есть база меток, все метки в таблицах в основной схеме.
Есть пользователи, которым не нужна вся база, а только определенные категории и метки в них. Делаем другую схему, а в ней можно сделать представления (view) которые "смотрят" на таблицы из основной схемы. Имена представлений совпадают с именами таблиц. Я проверял - САСПланете все равно представление это или таблица - лишь бы имя совпадало.

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

--
т.е. схемы - это и безопасность и красота и ускорение загрузки, если меток много. Вот такие мысли...

(0017941)
zed   
09-05-2017 09:42   
По мотивам тикета 0003218 - в ночнушке появилась возможность отвязаться от dbo схемы в MS SQL (настройка Forced Schema Name). У фреймворка нашлась соответствующая опция.