BDE , ADO и MSSQL

← →
mate © (2003-02-13 11:47) [0]

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

← →
stone © (2003-02-13 12:01) [1]

Почитай в Books Online о строковых типах данных и функциях LTRIM и RTRIM

← →
sniknik © (2003-02-13 12:02) [2]

по моему проще всего повесится ... :-)) на событие onGetText и делать усечение строке RightTrim().

← →
Zelius © (2003-02-13 12:10) [3]

ТО что ты описал, по идее, относится только к типу char, попробуй использовать varchar! Причем, после перевода поля к типу varchar принудительно удали все пробелы, а то они могут там застрять.

← →
jocko (2003-02-13 12:14) [4]

если они так отображаются, то может в базе действительно хранится строка с пробелами и бде и адо тут не причем.
вообще мне такая проблема не попадалась ни разу.
Мне кажется ты когда вставляешь значения в поля таблицы БД где-то используешь переменные типа char вместо varchar вот он и добавляет лишних пробелов.
если поле в таблице varchar и лишние пробелы есть, то напиши скрипт и отработай усечение лишних пробелов во всей таблице скопом.

← →
mate © (2003-02-13 12:58) [5]

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

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

← →
mate © (2003-02-13 13:00) [6]

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

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

← →
stone © (2003-02-13 13:04) [7]

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

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

← →
sniknik © (2003-02-13 13:42) [8]

забавная вещь получается, похоже 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 он так действует при передаче строк? в обшем вопросов больше чем ответов. требуется дополнительное тестирование (потом когданибудь, может быть, работать тоже надо)

← →
sniknik © (2003-02-13 14:24) [9]

во бред. продолжил дальше (игнорируя работу) и изменил уже с VARCHAR(255) (со значениями уже усеченными) на VARCHAR(20), и все осталось правильно, длинна такая как и записано без добавления пробелов. (даже если заносить "gghh ", усекается) ну и как тут выводы делать, каким образом он работает? похоже как ему захочется :-)).

← →
jocko (2003-02-13 14:34) [10]

А ты как тип менял?
ради интереса запусти Enterprise Manager открой заранее подготовленную табличку скажем Сreate table t1(c char(20)) затем открой свойства и измени тип поля, а затем сохрани изменения как скрипт и посмотри в него... ты также сделал как он?

← →
Anatoly Podgoretsky © (2003-02-13 14:35) [11]

VARCHAR ни чего не говорит о хранении - это сам сервер решает как, например для Интербейс для CHAR и VARCHAR хранение абсолютно одинаковое, а вот выдача по запросу уже будет отличаться. В это дело могут вмешиваться промежуточные компоненты и делать это не в соотвествии со стандартом.
Последнее может объяснить " похоже как ему захочется"

← →
jocko (2003-02-13 14:42) [12]

>даже если заносить "gghh ", усекается
?!

← →
sniknik © (2003-02-13 14:45) [13]

примерно так и делал, могу прям счас повторить
выполняю запрос (через ADO)
CREATE TABLE t1 (id INT IDENTITY(1,1), c CHAR(20))
открываю так же через ADO, через датасет режим директтабле. добавляю пару значений по нескольку символов, получаем описаный результат. дальше по пунктам, изменял тип в Enterprise Manager естественно (проше всего, если бы ALTER TABLE с добавлением заменой сделал то может быть и не получилось бы).

← →
sniknik © (2003-02-13 14:47) [14]

jocko (13.02.03 14:42)
>даже если заносить "gghh ", усекается

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

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

Может в эту сторону "копать" надо:
SET ANSI_PADDING ON | OFF

еще одно изначально созданный с VARCHAR
CREATE TABLE t2 (id INT IDENTITY(1,1), c VARCHAR(20))

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

← →
jocko (2003-02-13 14:57) [17]

интересненько я исп 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)
видимо зависит от того как менять таблицу

То есть видишь, что не в VARCHAR дело

да точно, таблица созданная с
SET ANSI_PADDING OFF
и созданая с
SET ANSI_PADDING ON
имеют разные свойства применительно к строкам (OFF усекаются при занесении "fjf " пробелов) в Bol еще и про варбинари чегото но наверное аналог.

BDE , ADO и MSSQL Найти похожие ветки