Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

BDE , ADO и MSSQL [D5, MSSQL]

mate © (2003-02-13 11:47:00)
У меня есть база на MSSQL когда я к ней обращался через BDE Администратор всё было нормально, т.е. какую я запись ввёл та и отображается. Теперь переделал на ADO и записи (с типом и char и varchar) показываются с пробелами до конца длины записи , т.е. если запись "форум" , а ограничение на длину стоит 25 символов , то в DBGride будет написано "форум"+20 пробелов. Как сделать что бы пробелов не было и я мог редактировать записи.

sniknik (2003-02-13 15:11:00) [1]
да точно, таблица созданная с
SET ANSI_PADDING OFF
и созданая с
SET ANSI_PADDING ON
имеют разные свойства применительно к строкам (OFF усекаются при занесении "fjf " пробелов) в Bol еще и про варбинари чегото но наверное аналог.

Anatoly Podgoretsky (2003-02-13 15:06:00) [2]
То есть видишь, что не в VARCHAR дело

sniknik (2003-02-13 14:59:00) [3]
Владислав © (13.02.03 14:48)
ну вот похоже и обьяснение. :-))) теперь стало понатнее. (буду спать спокойнее :-)))

jocko (2003-02-13 14:57:00) [4]
интересненько я исп Query Analiser

create table t1(c char(20)) insert t1 (c) values ("1")
здесь тот самый код который сгенерировался:

BEGIN TRANSACTION SET QUOTED_IDENTIFIER ON SET TRANSACTION ISOLATION LEVEL SERIALIZABLE SET ARITHABORT ON SET NUMERIC_ROUNDABORT OFF SET CONCAT_NULL_YIELDS_NULL ON SET ANSI_NULLS ON SET ANSI_PADDING ON SET ANSI_WARNINGS ON COMMIT BEGIN TRANSACTION CREATE TABLE dbo.Tmp_t1 ( c varchar(20) NULL ) ON [PRIMARY] GO IF EXISTS(SELECT * FROM dbo.t1) EXEC("INSERT INTO dbo.Tmp_t1 (c) SELECT CONVERT(varchar(20), c) FROM dbo.t1 TABLOCKX") GO DROP TABLE dbo.t1 GO EXECUTE sp_rename N"dbo.Tmp_t1", N"t1", "OBJECT" GO COMMIT
теперь еще вставочка:
insert t1 (c) values ("2 ") select c from t1 drop table t1
все как часы и правильно за исключением пробелов ... (beep)
видимо зависит от того как менять таблицу

sniknik (2003-02-13 14:53:00) [5]
еще одно изначально созданный с VARCHAR
CREATE TABLE t2 (id INT IDENTITY(1,1), c VARCHAR(20))

таких глюков не имеет (то есть тут сразу все правильно заносиш 3 символа столько же в гриде).

Владислав (2003-02-13 14:48:00) [6]
Может в эту сторону "копать" надо:
SET ANSI_PADDING ON | OFF

sniknik (2003-02-13 14:47:00) [7]
jocko (13.02.03 14:42)
>даже если заносить "gghh ", усекается

ага
INSERT INTO t1 (c) VALUES ("ytyt ")

после в гриде видим "ytyt"

sniknik (2003-02-13 14:45:00) [8]
примерно так и делал, могу прям счас повторить
выполняю запрос (через ADO)
CREATE TABLE t1 (id INT IDENTITY(1,1), c CHAR(20))
открываю так же через ADO, через датасет режим директтабле. добавляю пару значений по нескольку символов, получаем описаный результат. дальше по пунктам, изменял тип в Enterprise Manager естественно (проше всего, если бы ALTER TABLE с добавлением заменой сделал то может быть и не получилось бы).

jocko (2003-02-13 14:42:00) [9]
>даже если заносить "gghh ", усекается
?!

Anatoly Podgoretsky (2003-02-13 14:35:00) [10]
VARCHAR ни чего не говорит о хранении - это сам сервер решает как, например для Интербейс для CHAR и VARCHAR хранение абсолютно одинаковое, а вот выдача по запросу уже будет отличаться. В это дело могут вмешиваться промежуточные компоненты и делать это не в соотвествии со стандартом.
Последнее может объяснить " похоже как ему захочется"

jocko (2003-02-13 14:34:00) [11]
А ты как тип менял?
ради интереса запусти Enterprise Manager открой заранее подготовленную табличку скажем Сreate table t1(c char(20)) затем открой свойства и измени тип поля, а затем сохрани изменения как скрипт и посмотри в него... ты также сделал как он?

sniknik (2003-02-13 14:24:00) [12]
во бред. продолжил дальше (игнорируя работу) и изменил уже с VARCHAR(255) (со значениями уже усеченными) на VARCHAR(20), и все осталось правильно, длинна такая как и записано без добавления пробелов. (даже если заносить "gghh ", усекается) ну и как тут выводы делать, каким образом он работает? похоже как ему захочется :-)).

sniknik (2003-02-13 13:42:00) [13]
забавная вещь получается, похоже MSSQL имеет какойто встроеный "интелектуальный" определитель/заменитель типов. поясню.

попытался воспроизвести ситуацию, сделал таблицу
поле Name CHAR(20) - ситуация один в один даже если внесли значение в 1 символ длинной в гриде дополняются пробелами.

меняю поле на VARCHAR(20)
ситуация не меняется.
делаю
UPDATE TableTest SET NAME = RTRIM(NAME)
смотрю в гриде ничего не изменилось.

меняю поле на VARCHAR(255)
ситуация не меняется.
делаю
UPDATE TableTest SET NAME = RTRIM(NAME)
вот тут все и пришло в норму, если строка 3символа длинной то в гриде так и есть без пробелов в конце.

вывод: MSSQL сам может решать как ему хранить данные, даже если указано VARCHAR - будет в CHAR если решит что так выгоднее.
???????

На самом деле CHAR быстрее и выгоднее во многих случаях в BOL предлагают самим решать какой тип лутше использовать. А получается не всегда наше решение главное?

Попробовал то же самое подключившись к Access, сошлось во всех деталях. Т.е микрософтские продукты написаны одинаково? или это особенность ADO он так действует при передаче строк? в обшем вопросов больше чем ответов. требуется дополнительное тестирование (потом когданибудь, может быть, работать тоже надо)

stone (2003-02-13 13:04:00) [14]

> Если я буду пользоваться эти в запросе то я не смогу редактировать
> записи.

А этим не нужно пользоваться в запросе, это надо сделать один раз см. Zelius © (13.02.03 12:10)

mate (2003-02-13 13:00:00) [15]

> Zelius © (13.02.03 12:10)
> ТО что ты описал, по идее, относится только к типу char,
> попробуй использовать varchar! Причем, после перевода поля
> к типу varchar принудительно удали все пробелы, а то они
> могут там застрять.

Ну через BDE пробелов-то нет, а через ADO есть, и тип я менял - не помогло...

mate (2003-02-13 12:58:00) [16]

> stone © (13.02.03 12:01)
> Почитай в Books Online о строковых типах данных и функциях
> LTRIM и RTRIM

Если я буду пользоваться эти в запросе то я не смогу редактировать записи.

jocko (2003-02-13 12:14:00) [17]
если они так отображаются, то может в базе действительно хранится строка с пробелами и бде и адо тут не причем.
вообще мне такая проблема не попадалась ни разу.
Мне кажется ты когда вставляешь значения в поля таблицы БД где-то используешь переменные типа char вместо varchar вот он и добавляет лишних пробелов.
если поле в таблице varchar и лишние пробелы есть, то напиши скрипт и отработай усечение лишних пробелов во всей таблице скопом.

Zelius (2003-02-13 12:10:00) [18]
ТО что ты описал, по идее, относится только к типу char, попробуй использовать varchar! Причем, после перевода поля к типу varchar принудительно удали все пробелы, а то они могут там застрять.

sniknik (2003-02-13 12:02:00) [19]
по моему проще всего повесится ... :-)) на событие onGetText и делать усечение строке RightTrim().

stone (2003-02-13 12:01:00) [20]
Почитай в Books Online о строковых типах данных и функциях LTRIM и RTRIM

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »