|
|
|
Warining сервера
|
|||
|---|---|---|---|
|
#18+
собственно ситуация следующая. есть таблица скажем следующей стркутуры. ID: int fld1: float fld2: float varchar1: varchar(8000) varchar2: varchar(8000) при создании таблицы в EM'е все нормально, однако, если воспользоваться QA вылетает предупреждение типа Warning: The table 'ShadowBenchmarkMain' has been created but its maximum row size (8294) exceeds the maximum number of bytes per row (8060). INSERT or UPDATE of a row in this table will fail if the resulting row length exceeds 8060 bytes. В общем перевод мне не нужен, хотелось бы знать, в какую сторону копать, как по другому организовать структуру. и еще как дополнение к описанию таблицы: в varchar1/2 хранятся части SQL-запросов, которые затем используются внутри ХП с помощью EXEC. Можно ли изменить varchar(8000) на text, а затем воспользоваться EXEC? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2002, 12:19:17 |
|
||
|
Warining сервера
|
|||
|---|---|---|---|
|
#18+
в какую сторону копать, как по другому организовать структуру. Например, создать 2 таблицы. В 1-ой ID: int fld1: float fld2: float Во 2-ой FK_ID: int record_id:int sql_string: varchar(8000) Ну или одну(если не хотите нормализовать) ID: int fld1: float fld2: float sql_string_nr: int sql_string: varchar(8000) Можно ли изменить varchar(8000) на text, а затем воспользоваться EXEC? Только как вы передадите EXEC-у ваше text поле ? Ведь локальные переменные типа text нельзя объявить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2002, 12:57:51 |
|
||
|
Warining сервера
|
|||
|---|---|---|---|
|
#18+
Прежде чем копать, нужно попытаться понять, а нужно ли это вообще делать. Сначала нужно осмыслить причину всего происходящего, а потом уже бороться либо с ней, либо с чем-то другим. Размер данных, которые можно уместить в одной записи таблицы (за исключением TEXT и IMAGE) не может превосходить 8060 байт. Когда ты создаешь таблицу, в которой потенциально может поместиться информации юольше, SQL-сервер выдает тебе об этом предупреждение. Если алгоритмы работы твоего приложения гарантируют, что суммарный объем записи никогда не превысит 8060 байт, просто плюнь на это предупреждение и не обращай внимания. Если же может возникнуть ситуация, когда тебе на самом деле понадобится сохранить, к примеру, в varchar1 значение длиной в 6500 байт и в varchar2 - значение длиной в 5000 байт, то суммарный объем данных, которые пытаются сохраниться в одной записи превысит предел в 8060 байт, выскочит сообщение об ошибке, а данные сохранены не будут. Так вот, прежде чем далее воевать, необходимо выяснить, с чем именно мы воюем. Если нужно просто подавить выдачу предупреждения - вопрос один. Если вопрос состоит в том, а следует ли обращать на него внимание, лучше тебя на него никто ответить не сможет. Если вопрос состоит в том, как сохранить данные в одной записи, объем которых превышает 8060 байт, то возможны два варианта - разбивание таблицы на несколько связанных друг с другом таблиц, либо использование TEXT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2002, 13:21:04 |
|
||
|
Warining сервера
|
|||
|---|---|---|---|
|
#18+
Вообще говоря, сам SQL Server элегантно обходит эту проблему простым разбиением одной "большой" записи на несколько (таблица syscomments) меньших. Удачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2002, 13:25:25 |
|
||
|
Warining сервера
|
|||
|---|---|---|---|
|
#18+
2jimmers Было-бы намного элегантней, если-бы сервер нормально работал-бы с данными типа text/image ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2002, 13:27:50 |
|
||
|
Warining сервера
|
|||
|---|---|---|---|
|
#18+
2alexeyvg: Простите, что Вас не устраивает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2002, 13:32:38 |
|
||
|
Warining сервера
|
|||
|---|---|---|---|
|
#18+
спасибо всем... 2 Glory насчет двух таблиц, я понял. действительно можно попробовать и так сделать (первый вариант, конечно) а насчет EXEC + TEXT - именно в этом и был вопрос, можно ли суметь воспользоваться такой конструкцией или нет. Как я понимаю - нет. 2Garya Как я уже писал, данные представляют собой части SQL-запроса, которые гипотетически в сумме могут превышать 8060 байт, а, следовательно, эти данные критичны. 2 jimmers меня, например, тоже не совсем устраивает невозможность использовать в подавляющем большинстве случаев поля типа ntext/text, т.к. реально практически нет функций по обработке этих типов данных. В общем, всем спасибо. Теперь у меня наметилось два решения 1. создание двух таблиц 2. использование поля типа text, которое потом ковертить к типу varchar для работы. в этом случае надо будет гарантировать длину text в 8000 символов. Кто какой вариант предпочел бы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2002, 14:07:54 |
|
||
|
|

start [/forum/topic.php?fid=46&gotonew=1&tid=1820463]: |
0ms |
get settings: |
12ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
93ms |
get topic data: |
13ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
| others: | 242ms |
| total: | 464ms |

| 0 / 0 |
