Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2003.03.03;
Скачать: [xml.tar.bz2];

Вниз

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"


 
Владислав   (2003-02-13 14:48) [15]

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


 
sniknik   (2003-02-13 14:53) [16]

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



 
sniknik   (2003-02-13 14:59) [18]

Владислав © (13.02.03 14:48)
ну вот похоже и обьяснение. :-))) теперь стало понатнее. (буду спать спокойнее :-)))


 
Anatoly Podgoretsky   (2003-02-13 15:06) [19]

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


 
sniknik   (2003-02-13 15:11) [20]

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2003.03.03;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.62 MB
Время: 0.049 c
1-5583
AlexanderSK
2003-02-19 16:17
2003.03.03
Uses


1-5614
Kair
2003-02-20 05:32
2003.03.03
OpenDialog


14-5738
New
2003-02-15 09:32
2003.03.03
Проблема с определением логина


14-5817
V-Isa
2003-02-12 15:46
2003.03.03
Просмотр каталогов и файлов.


4-5907
Cosmic
2002-12-04 23:26
2003.03.03
SHBrowseForFolder





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский