SASGIS - SAS.Планета |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0002897 | SAS.Планета | [All Projects] Баг | public | 07-11-2015 21:06 | 09-05-2017 09:42 |
|
| Reporter | sheavy | |
| Assigned To | zed | |
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | not fixable | |
| Platform | Windows | OS | 7 | OS Version | Professional |
| Product Version | 151111 | |
| Target Version | | Fixed in Version | | |
|
| Summary | 0002897: Пропадают некоторые метки после импорта в MS SQL и рестарта программы |
| Description | После импорта программа ведет себя безупречно. Категории открываются быстро, ничего не пропадает. Но после рестарта больше половина меток почему-то не показывается и программа начинает тормозить как будто не может получить чей-то отклик. Метки пропадают каждый раз одни и те же. |
| Steps To Reproduce | |
| Additional Information | смотрите пример меток во вложенных файлах |
| Tags | БД, метки |
| Relationships | |
| Attached Files |  markshide.sml (248,560) 07-11-2015 21:06
https://bugtracker.sasgis.org/file_download.php?file_id=1968&type=bug
Categorymarkshide.sml (1,600) 07-11-2015 21:07
https://bugtracker.sasgis.org/file_download.php?file_id=1969&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 07-11-2015 21:06 | sheavy | New Issue | |
| 07-11-2015 21:06 | sheavy | File Added: markshide.sml | |
| 07-11-2015 21:07 | sheavy | File Added: Categorymarkshide.sml | |
| 07-11-2015 21:08 | sheavy | Tag Attached: БД | |
| 07-11-2015 21:08 | sheavy | Tag Attached: метки | |
| 08-11-2015 15:26 | zed | Note Added: 0016755 | |
| 08-11-2015 15:27 | zed | Status | new => confirmed |
| 09-11-2015 11:20 | vdemidov | Assigned To | => zed |
| 09-11-2015 11:20 | vdemidov | Status | confirmed => assigned |
| 09-11-2015 11:20 | vdemidov | Target Version | => 151111 |
| 10-11-2015 06:26 | zed | Note Added: 0016772 | |
| 10-11-2015 06:26 | zed | Status | assigned => feedback |
| 10-11-2015 10:57 | zed | Note Added: 0016773 | |
| 10-11-2015 10:58 | zed | Target Version | 151111 => 191221 |
| 11-11-2015 11:40 | sheavy | Note Added: 0016778 | |
| 11-11-2015 11:40 | sheavy | Status | feedback => assigned |
| 11-11-2015 11:40 | sheavy | Note Edited: 0016778 | bug_revision_view_page.php?bugnote_id=16778#r6779 |
| 11-11-2015 11:42 | sheavy | Note Added: 0016779 | |
| 11-11-2015 18:36 | zed | Note Added: 0016785 | |
| 11-11-2015 18:37 | zed | Note Added: 0016786 | |
| 11-11-2015 18:37 | zed | Note Edited: 0016785 | bug_revision_view_page.php?bugnote_id=16785#r6781 |
| 15-11-2015 14:52 | sheavy | Note Added: 0016834 | |
| 15-11-2015 14:57 | zed | Note Added: 0016835 | |
| 15-11-2015 15:06 | sheavy | Note Added: 0016836 | |
| 15-11-2015 15:07 | sheavy | Note Edited: 0016836 | bug_revision_view_page.php?bugnote_id=16836#r6802 |
| 18-11-2015 09:58 | vdemidov | Product Version | .Nightly => 151111 |
| 18-11-2015 09:58 | vdemidov | Target Version | 191221 => 160606 |
| 11-05-2016 08:16 | zed | Status | assigned => closed |
| 11-05-2016 08:16 | zed | Resolution | open => not fixable |
| 13-05-2016 07:20 | vdemidov | Target Version | 160606 => |
| 09-05-2017 09:42 | zed | Note 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). У фреймворка нашлась соответствующая опция. |
|