gal 7.11 MSSQL, Enterprise архитектура.
МЕдленно схожу с ума. Может кто прояснит ситуацию.
Есть общая на несколько баз табла USERDESKREP.
В ней есть некое поле TEXTDATA типа LVar, короче мемо оно. И мемо данные храняться именно в этой таблице, именно в этом поле.
Так вот, все поля кроме этого видны в остальных базах. А содержимое этого TEXTDATA видно только в основной.
Чего делать? Или хоть суть поясните как так.
Enterprise. Таблица общая, а некоторые поля нет !???
Модераторы: m0p3e, edward_K, Модераторы
-
- Местный житель
- Сообщения: 289
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Saint-Petersburg
- Контактная информация:
gal 7.11 MSSQL, Enterprise архитектура
Есть отличия в реализации MEMO-полей под Pervasive и под MS SQL.
В Pervasive MEMO-поле содержится в самой таблице, и имеет тип LVAR, кстати, в версии 7.12 поля TEXTDATA в таблице USERDESKREP что-то не видать.
В MS SQL, если смотреть Enterprise Manager, в таблице T$USERDESKREP поле F$TEXTDATA имеет тип BIT, и может приинмать только значения 1 и 0 (TRUE, FALSE). Судя по всему данное поле является лишь ссылкой на наличие или отсутствие MEMO-данных. Сами данные, вероятно, располагаются в таблице XX$MEMO. Если посмотреть триггер на вставку по таблице T$USERDESKREP, то там можно увидеть целый блок по записи мемо в таблицу XX$MEMO.
Однако, в рамках SUPPORT таблицу XX$MEMO увидеть нельзя, т.е. нельзя ее включить и в Enterprise-архитектуру, так что вывод...
В Pervasive MEMO-поле содержится в самой таблице, и имеет тип LVAR, кстати, в версии 7.12 поля TEXTDATA в таблице USERDESKREP что-то не видать.
В MS SQL, если смотреть Enterprise Manager, в таблице T$USERDESKREP поле F$TEXTDATA имеет тип BIT, и может приинмать только значения 1 и 0 (TRUE, FALSE). Судя по всему данное поле является лишь ссылкой на наличие или отсутствие MEMO-данных. Сами данные, вероятно, располагаются в таблице XX$MEMO. Если посмотреть триггер на вставку по таблице T$USERDESKREP, то там можно увидеть целый блок по записи мемо в таблицу XX$MEMO.
Однако, в рамках SUPPORT таблицу XX$MEMO увидеть нельзя, т.е. нельзя ее включить и в Enterprise-архитектуру, так что вывод...
Нормальная архитектура
Просто не совсем корректно пользовательсткую таблицу делать разделяемой. Но при достаточном уровне знаний об устройстве БД даже это можно сделать.
-
- Местный житель
- Сообщения: 291
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: С-Петербург
- Контактная информация:
Ну может быть не совсем корректно.
Но разве более корректно предусматривать распределенную архитекуру и при этом хранить достаточно важные данные (ничего, что ни один отчет модуля планирование не построить в подчиненных базах), так вот хранить эти данные в таблице, которая не может быть общей.
И если не секрет, то какими знаниями нужно обладать, чтобы все же решить проблему?
Я уж думаю, может триггер как-то подправить. Но страшновато вообще.
Но разве более корректно предусматривать распределенную архитекуру и при этом хранить достаточно важные данные (ничего, что ни один отчет модуля планирование не построить в подчиненных базах), так вот хранить эти данные в таблице, которая не может быть общей.
И если не секрет, то какими знаниями нужно обладать, чтобы все же решить проблему?
Я уж думаю, может триггер как-то подправить. Но страшновато вообще.