FoxClub Forums > Visual Foxpro, Foxpro for DOS > Зачем были созданы новые типы данных? ::

• Войти

Страницы: 1 2

Re: Зачем были созданы новые типы данных?
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004	piva 22.09.04 12:46:39 Вот ведь а на MapBinary не взглянул даже - приятно обрадован Еще раз спасибо. ------------------ Часто бывает так, что есть над чем задуматься, а нечем.

Re: Зачем были созданы новые типы данных?
Владимир Максимов Автор Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000	Владимир Максимов 23.09.04 13:09:08 Цитата: Цитата: При работе с полями Char обойти проблему SET EXACT и SET ANSI довольно просто, добавив концевые пробелы к символьным выражениям: =SEEK(PADR("test",10)) Такой поиск будет правильным вне зависимости от SET EXACT А вот с VarChar такой фокус не пройдет Да? Это почему же? Да, с функцией SEEK() пример не очень удачен, более показателен пример с InList() или IN со списком в Select-SQL InList(MyTab.MyField, PADR("1",10), PADR("2",10)) Даже если в таблице есть значения полей "11" и "12", то тем не менее для типов Character будут найдены записи только со значениями "1" и "2", поскольку у них есть концевые пробелы. Причем в таком виде результат работы никак не зависит от настройки SET EXACT. А как решить ту же задачу для VarChar, кроме как установкой нужной настройки SET EXACT? Цитата: Ничего страшного если вы не видите немедленное применение этого типа в своих приложениях. Когда появится надобность, функциональность уже на месте. Делать заключение "включен ТОЛЬКО для совместимости с серверными базами данных" - это загонять себя в какие-то, искуственно созданные, границы в выборе средств в будущем. А озвучивать его на всю "вселенную" - это еще и загонять в эти границы других людей. Вообще-то, я выразился более осторожно. Ну, ладно, будем считать, что раз есть инструмент, то применение ему всегда найдется. ------------------

Re: Зачем были созданы новые типы данных?

Владимир Максимов
Автор

Сообщений: 14097
Откуда: Москва
Дата регистрации: 02.09.2000

Владимир Максимов

23.09.04 13:09:08

Цитата:
Цитата:
При работе с полями Char обойти проблему SET EXACT и SET ANSI довольно просто, добавив концевые пробелы к символьным выражениям:
=SEEK(PADR("test",10))

Такой поиск будет правильным вне зависимости от SET EXACT

А вот с VarChar такой фокус не пройдет
Да? Это почему же?

Да, с функцией SEEK() пример не очень удачен, более показателен пример с InList() или IN со списком в Select-SQL

InList(MyTab.MyField, PADR("1",10), PADR("2",10))

Даже если в таблице есть значения полей "11" и "12", то тем не менее для типов Character будут найдены записи только со значениями "1" и "2", поскольку у них есть концевые пробелы. Причем в таком виде результат работы никак не зависит от настройки SET EXACT.

А как решить ту же задачу для VarChar, кроме как установкой нужной настройки SET EXACT?

Цитата:
Ничего страшного если вы не видите немедленное применение этого типа в своих приложениях. Когда появится надобность, функциональность уже на месте. Делать заключение "включен ТОЛЬКО для совместимости с серверными базами данных" - это загонять себя в какие-то, искуственно созданные, границы в выборе средств в будущем. А озвучивать его на всю "вселенную" - это еще и загонять в эти границы других людей.

Вообще-то, я выразился более осторожно. Ну, ладно, будем считать, что раз есть инструмент, то применение ему всегда найдется.

------------------

Re: Зачем были созданы новые типы данных?
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 23.09.04 14:44:17 Hi, Владимир! Совершенно не понял твоего примера, если можно - приведи полный вариант - создание курсора (с Char и Varchar соответственно), наполнение тестовыми данными, исполнение запросов с разными SET-ами, ибо я вот например не вижу что тут и чем отличается... при отборе из varchar PADR() точно так-же помогает как и для просто char... Или я чего-то в упор не вижу ------------------ WBR, Igor

Re: Зачем были созданы новые типы данных?

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

23.09.04 14:44:17

Hi, Владимир!

Совершенно не понял твоего примера, если можно - приведи полный вариант -
создание курсора (с Char и Varchar соответственно), наполнение тестовыми
данными, исполнение запросов с разными SET-ами, ибо я вот например не вижу
что тут и чем отличается... при отборе из varchar PADR() точно так-же
помогает как и для просто char... Или я чего-то в упор не вижу

------------------
WBR, Igor

Re: Зачем были созданы новые типы данных?
Владимир Максимов Автор Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000	Владимир Максимов 23.09.04 20:07:51 CREATE CURSOR test (f1 V(10), f2 C(10)) INSERT INTO test VALUES ("1","1") INSERT INTO test VALUES ("11","11") INSERT INTO test VALUES ("111","111") * Необходимо отобрать записи, имеющие значение "1" или "11" CLEAR SET EXACT OFF ?"SET EXACT OFF" select test SCAN ?f1,InList(f1,PADR("1",10),PADR("11",10)),InList(f1,"1","11") ?f2,InList(f2,PADR("1",10),PADR("11",10)),InList(f2,"1","11") ENDSCAN SET EXACT ON ?"SET EXACT ON" select test SCAN ?f1,InList(f1,PADR("1",10),PADR("11",10)),InList(f1,"1","11") ?f2,InList(f2,PADR("1",10),PADR("11",10)),InList(f2,"1","11") ENDSCAN Т.е. для полей типа Character в случае добавления концевых пробелов абсолютно не имеет значения настройка SET EXACT. Результат сравнения от этого не изменится. Но для полей VarChar это имеет принципиальное значение. Хотя в Select-SQL логика совершенно другая. Впрочем, такая же логика при работе с полями VarChar и в MS SQL. Просто об этом надо знать SELECT * FROM test WHERE InList(f1,PADR("1",100),PADR("11",100)) ------------------

Re: Зачем были созданы новые типы данных?

Владимир Максимов
Автор

Сообщений: 14097
Откуда: Москва
Дата регистрации: 02.09.2000

Владимир Максимов

23.09.04 20:07:51


CREATE CURSOR test (f1 V(10), f2 C(10))
INSERT INTO test VALUES ("1","1")
INSERT INTO test VALUES ("11","11")
INSERT INTO test VALUES ("111","111")
* Необходимо отобрать записи, имеющие значение "1" или "11"
CLEAR
SET EXACT OFF
?"SET EXACT OFF"
select test
SCAN
    ?f1,InList(f1,PADR("1",10),PADR("11",10)),InList(f1,"1","11")
    ?f2,InList(f2,PADR("1",10),PADR("11",10)),InList(f2,"1","11")
ENDSCAN
SET EXACT ON
?"SET EXACT ON"
select test
SCAN
    ?f1,InList(f1,PADR("1",10),PADR("11",10)),InList(f1,"1","11")
    ?f2,InList(f2,PADR("1",10),PADR("11",10)),InList(f2,"1","11")
ENDSCAN

Т.е. для полей типа Character в случае добавления концевых пробелов абсолютно не имеет значения настройка SET EXACT. Результат сравнения от этого не изменится. Но для полей VarChar это имеет принципиальное значение.

Хотя в Select-SQL логика совершенно другая. Впрочем, такая же логика при работе с полями VarChar и в MS SQL. Просто об этом надо знать


SELECT * FROM test WHERE InList(f1,PADR("1",100),PADR("11",100))

------------------

Re: Зачем были созданы новые типы данных?
Aleksey Tsingauz [MSFT]	Aleksey Tsingauz [MSFT] 23.09.04 22:43:38 Цитата: Т.е. для полей типа Character в случае добавления концевых пробелов абсолютно не имеет значения настройка SET EXACT. Результат сравнения от этого не изменится. Но для полей VarChar это имеет принципиальное значение. Ну дак если начинать писать "безопасный" код, то надо быть последовательным до коца. Вот этот код и для Char выдает разные результаты: CREATE CURSOR test (f1 V(10), f2 C(11)) INSERT INTO test VALUES ("1", "1 1") INSERT INTO test VALUES ("11", "11 1") INSERT INTO test VALUES ("111","111 1") CLEAR SET EXACT OFF ?"SET EXACT OFF" select test SCAN ?"f1",f1,InList(f1,PADR("1",10),PADR("11",10)) ?"f2",f2,InList(f2,PADR("1",10),PADR("11",10)) ENDSCAN SET EXACT ON ?"SET EXACT ON" select test SCAN ?"f1",f1,InList(f1,PADR("1",10),PADR("11",10)) ?"f2",f2,InList(f2,PADR("1",10),PADR("11",10)) ENDSCAN SET EXACT OFF f1 1 .F. f2 1 1 .T. f1 11 .F. f2 11 1 .T. f1 111 .F. f2 111 1 .F. SET EXACT ON f1 1 .T. f2 1 1 .F. f1 11 .T. f2 11 1 .F. f1 111 .F. f2 111 1 .F. А вот так, для обоих типов результат не зависит от SET EXACT: CREATE CURSOR test (f1 V(10), f2 C(11)) INSERT INTO test VALUES ("1", "1 1") INSERT INTO test VALUES ("11", "11 1") INSERT INTO test VALUES ("111","111 1") CLEAR SET EXACT OFF ?"SET EXACT OFF" select test SCAN ?"f1",f1,InList(PADR(f1,10),PADR("1",10),PADR("11",10)) ?"f2",f2,InList(PADR(f2,10),PADR("1",10),PADR("11",10)) ENDSCAN SET EXACT ON ?"SET EXACT ON" select test SCAN ?"f1",f1,InList(PADR(f1,10),PADR("1",10),PADR("11",10)) ?"f2",f2,InList(PADR(f2,10),PADR("1",10),PADR("11",10)) ENDSCAN SET EXACT OFF f1 1 .T. f2 1 1 .T. f1 11 .T. f2 11 1 .T. f1 111 .F. f2 111 1 .F. SET EXACT ON f1 1 .T. f2 1 1 .T. f1 11 .T. f2 11 1 .T. f1 111 .F. f2 111 1 .F.

Re: Зачем были созданы новые типы данных?

Aleksey Tsingauz [MSFT]

23.09.04 22:43:38

Цитата:
Т.е. для полей типа Character в случае добавления концевых пробелов абсолютно не имеет значения настройка SET EXACT. Результат сравнения от этого не изменится. Но для полей VarChar это имеет принципиальное значение.

Ну дак если начинать писать "безопасный" код, то надо быть последовательным до коца.
Вот этот код и для Char выдает разные результаты:


  CREATE CURSOR test (f1 V(10), f2 C(11))  
  INSERT INTO test VALUES ("1",  "1         1")  
  INSERT INTO test VALUES ("11", "11        1")  
  INSERT INTO test VALUES ("111","111       1")  
    
  CLEAR  
  SET EXACT OFF  
  ?"SET EXACT OFF"  
  select test  
  SCAN  
      ?"f1",f1,InList(f1,PADR("1",10),PADR("11",10))  
      ?"f2",f2,InList(f2,PADR("1",10),PADR("11",10))
  ENDSCAN  
    
  SET EXACT ON  
  ?"SET EXACT ON"  
  select test  
  SCAN  
      ?"f1",f1,InList(f1,PADR("1",10),PADR("11",10))
      ?"f2",f2,InList(f2,PADR("1",10),PADR("11",10))
  ENDSCAN


SET EXACT OFF
f1 1 .F.
f2 1         1 .T.
f1 11 .F.
f2 11        1 .T.
f1 111 .F.
f2 111       1 .F.
SET EXACT ON
f1 1 .T.
f2 1         1 .F.
f1 11 .T.
f2 11        1 .F.
f1 111 .F.
f2 111       1 .F.

А вот так, для обоих типов результат не зависит от SET EXACT:


  CREATE CURSOR test (f1 V(10), f2 C(11))  
  INSERT INTO test VALUES ("1",  "1         1")  
  INSERT INTO test VALUES ("11", "11        1")  
  INSERT INTO test VALUES ("111","111       1")  
    
  CLEAR  
  SET EXACT OFF  
  ?"SET EXACT OFF"  
  select test  
  SCAN  
      ?"f1",f1,InList(PADR(f1,10),PADR("1",10),PADR("11",10))
      ?"f2",f2,InList(PADR(f2,10),PADR("1",10),PADR("11",10))
  ENDSCAN  
    
  SET EXACT ON  
  ?"SET EXACT ON"  
  select test  
  SCAN  
      ?"f1",f1,InList(PADR(f1,10),PADR("1",10),PADR("11",10))
      ?"f2",f2,InList(PADR(f2,10),PADR("1",10),PADR("11",10))
  ENDSCAN


SET EXACT OFF
f1 1 .T.
f2 1         1 .T.
f1 11 .T.
f2 11        1 .T.
f1 111 .F.
f2 111       1 .F.
SET EXACT ON
f1 1 .T.
f2 1         1 .T.
f1 11 .T.
f2 11        1 .T.
f1 111 .F.
f2 111       1 .F.

Re: Зачем были созданы новые типы данных?
Владимир Максимов Автор Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000	Владимир Максимов 24.09.04 10:03:50 Алексей, зачем же передергивать? Я сознательно никак не обрабатываю само поле с целью возможного использования индекса и rushmore-оптимизации: CREATE CURSOR test (f1 V(10), f2 C(10)) INSERT INTO test VALUES ("1","1") INSERT INTO test VALUES ("11","11") INSERT INTO test VALUES ("111","111") INDEX ON f1 TAG f1 INDEX ON f2 TAG f2 SET ORDER TO 0 CLEAR SET EXACT OFF ?"SET EXACT OFF" SELECT test SCAN FOR f1 = PADR("1",10) ?"f1",f1 ENDSCAN SCAN FOR f2 = PADR("1",10) ?"f2",f2 ENDSCAN SET EXACT ON ?"SET EXACT ON" SELECT test SCAN FOR f1 = PADR("1",10) ?"f1",f1 ENDSCAN SCAN FOR f2 = PADR("1",10) ?"f2",f2 ENDSCAN Кстати, почему Select-SQL не реагирует на настройку SET ANSI, когда речь идет о концевых пробелах, хотя, в принципе, должен SET ANSI ON SELECT * FROM test WHERE f1 = PADR("1",100) SET ANSI OFF SELECT * FROM test WHERE f1 = PADR("1",100) Ну, и заодно ;), почему такие странные результаты SYS(3054,1) в данных запросах? Т.е. Partial при SET ANSI ON и Full при SET ANSI OFF. ------------------

Re: Зачем были созданы новые типы данных?

Владимир Максимов
Автор

Сообщений: 14097
Откуда: Москва
Дата регистрации: 02.09.2000

Владимир Максимов

24.09.04 10:03:50

Алексей, зачем же передергивать? Я сознательно никак не обрабатываю само поле с целью возможного использования индекса и rushmore-оптимизации:


CREATE CURSOR test (f1 V(10), f2 C(10))
INSERT INTO test VALUES ("1","1")
INSERT INTO test VALUES ("11","11")
INSERT INTO test VALUES ("111","111")
INDEX ON f1 TAG f1
INDEX ON f2 TAG f2
SET ORDER TO 0
CLEAR
SET EXACT OFF
?"SET EXACT OFF"
SELECT test
SCAN FOR f1 = PADR("1",10)
    ?"f1",f1
ENDSCAN
SCAN FOR f2 = PADR("1",10)
    ?"f2",f2
ENDSCAN
SET EXACT ON
?"SET EXACT ON"
SELECT test
SCAN FOR f1 = PADR("1",10)
    ?"f1",f1
ENDSCAN
SCAN FOR f2 = PADR("1",10)
    ?"f2",f2
ENDSCAN

Кстати, почему Select-SQL не реагирует на настройку SET ANSI, когда речь идет о концевых пробелах, хотя, в принципе, должен


SET ANSI ON
SELECT * FROM test WHERE f1 = PADR("1",100)
SET ANSI OFF
SELECT * FROM test WHERE f1 = PADR("1",100)

Ну, и заодно ;), почему такие странные результаты SYS(3054,1) в данных запросах? Т.е. Partial при SET ANSI ON и Full при SET ANSI OFF.

------------------

Re: Зачем были созданы новые типы данных?
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 24.09.04 13:05:50 Hi, Владимир! Что-то ты всё больше смущаешь народ Я совершенно не понимаю твоих проблем с SET EXACT - ведь в хелпе всё сказано предельно ясно. Насчёт того что сравнивается пока не закончилась строка справа. SET EXACT OFF ? "1" = "1 " ? "1 " = "1" ? "1 " = "1 " И что тебя смущает в этом результате? varchar поле это "1" а не "1 ". Переставь местами операнды сравнения в FOR и получишь совершенно другой результат: SCAN FOR PADR("1",10) = f1 ?"f1",f1 ENDSCAN Цитата: Кстати, почему Select-SQL не реагирует на настройку SET ANSI IMHO реагирует в строгом соответствии с хелпом. При ON более короткая строка дополняется пробелами до длинны более длинной, про OFF - НЕ дополняется. Вот и все отличия - заметь это НЕ прямой аналог SET EXACT. EXACT может даже урезать более длинную строку для сравнения (если она слева), ANSI этого не делает. Псевдокод (ну т.к. реально SET ANSI вне SQL не учитывается): * при ANSI = ON ? "1 " = "1 " * при ANSI = OFF ? "1" = "1 " * или если переставить операнды ? "1 " = "1" Также попробуй эти-же запросы с переставленными условиями - WHERE PADR("1", 10) = f1 Цитата: Ну, и заодно ;), почему такие странные результаты SYS(3054,1) в данных запросах? Т.е. Partial при SET ANSI ON и Full при SET ANSI OFF. Учитывая что индексы (кроме бинарного) имеют формат с фиксированным размером, и учитывая что ты "добиваешь" выражение справа не до размера поля (это кстати нарочно 100 стоит или опечатка?) результаты вполне предсказуемые IMHO. ------------------ WBR, Igor

Re: Зачем были созданы новые типы данных?

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

24.09.04 13:05:50

Hi, Владимир!

Что-то ты всё больше смущаешь народ

Я совершенно не понимаю твоих проблем
с SET EXACT - ведь в хелпе всё сказано предельно ясно. Насчёт того что
сравнивается пока не закончилась строка справа.


SET EXACT OFF
? "1" = "1 "
? "1 " = "1"
? "1 " = "1 "

И что тебя смущает в этом результате? varchar поле это "1" а не "1 ".
Переставь местами операнды сравнения в FOR и получишь совершенно другой
результат:


SCAN FOR PADR("1",10) = f1
 ?"f1",f1
ENDSCAN

Цитата:
Кстати, почему Select-SQL не реагирует на настройку SET ANSI

IMHO реагирует в строгом соответствии с хелпом. При ON более короткая строка
дополняется пробелами до длинны более длинной, про OFF - НЕ дополняется. Вот
и все отличия - заметь это НЕ прямой аналог SET EXACT. EXACT может даже
урезать более длинную строку для сравнения (если она слева), ANSI этого не
делает. Псевдокод (ну т.к. реально SET ANSI вне SQL не учитывается):


* при ANSI = ON
? "1 " = "1 "
* при ANSI = OFF
? "1" = "1 "
* или если переставить операнды
? "1 " = "1"

Также попробуй эти-же запросы с переставленными условиями - WHERE PADR("1",
10) = f1

Цитата:
Ну, и заодно ;), почему такие странные результаты SYS(3054,1) в
данных запросах? Т.е. Partial при SET ANSI ON и Full при SET ANSI
OFF.

Учитывая что индексы (кроме бинарного) имеют формат с
фиксированным размером, и учитывая что ты "добиваешь" выражение
справа не до размера поля (это кстати нарочно 100 стоит или опечатка?)
результаты вполне предсказуемые IMHO.

------------------
WBR, Igor

Re: Зачем были созданы новые типы данных?
Владимир Максимов Автор Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000	Владимир Максимов 27.09.04 14:44:01 Цитата: SET EXACT Замнем... Я опять не смог ясно выразить свою мысль и ты меня не понял. Поскольку вопрос второстепенный, то прекращаю это обсуждение Цитата: SET ANSI Да, не обратил внимание, что эта настройка добавляет пробелы для более короткой строки не обращая внимания с какой стороны знака сравнения она стоит. В этом случае логика работы вполне понятна. ------------------

Re: Зачем были созданы новые типы данных?

Владимир Максимов
Автор

Сообщений: 14097
Откуда: Москва
Дата регистрации: 02.09.2000

Владимир Максимов

27.09.04 14:44:01

Цитата:
SET EXACT

Замнем... Я опять не смог ясно выразить свою мысль и ты меня не понял. Поскольку вопрос второстепенный, то прекращаю это обсуждение

Цитата:
SET ANSI

Да, не обратил внимание, что эта настройка добавляет пробелы для более короткой строки не обращая внимания с какой стороны знака сравнения она стоит. В этом случае логика работы вполне понятна.

------------------

Re: Зачем были созданы новые типы данных?
Aleksey Tsingauz [MSFT]	Aleksey Tsingauz [MSFT] 01.10.04 11:41:55 Здравствуйте, Владимир! Цитата: Я сознательно никак не обрабатываю само поле с целью возможного использования индекса и rushmore-оптимизации: Типы полей Varchar и Char отличаются, было бы бессмысленно добавлять новый тип абсолютно эдентичный старому. В поле Char хранятся данные фиксированной длины равной размеру поля. В поле Varchar хранятся данные переменной длины не превышающей размер поля. Длина строк играет существенное значение при сравнении с SET EXACT OFF, отсюда и разница в результатах, все согласно документации. Цитата: Кстати, почему Select-SQL не реагирует на настройку SET ANSI, когда речь идет о концевых пробелах, хотя, в принципе, должен SET ANSI ON SELECT * FROM test WHERE f1 = PADR("1",100) SET ANSI OFF SELECT * FROM test WHERE f1 = PADR("1",100) А как он должен реагировать? Цитата: Ну, и заодно ;), почему такие странные результаты SYS(3054,1) в данных запросах? Т.е. Partial при SET ANSI ON и Full при SET ANSI OFF. Я получаю None при SET ANSI OFF, потому что в данных условиях оптимизация не применяется. Aleksey Tsingauz Visual FoxPro Dev Team

Re: Зачем были созданы новые типы данных?

Aleksey Tsingauz [MSFT]

01.10.04 11:41:55

Здравствуйте, Владимир!

Цитата:
Я сознательно никак не обрабатываю само поле с целью возможного использования индекса и rushmore-оптимизации:

Типы полей Varchar и Char отличаются, было бы бессмысленно добавлять новый тип абсолютно эдентичный старому. В поле Char хранятся данные фиксированной длины равной размеру поля. В поле Varchar хранятся данные переменной длины не превышающей размер поля. Длина строк играет существенное значение при сравнении с SET EXACT OFF, отсюда и разница в результатах, все согласно документации.

Цитата:
Кстати, почему Select-SQL не реагирует на настройку SET ANSI, когда речь идет о концевых пробелах, хотя, в принципе, должен
SET ANSI ON
 SELECT * FROM test WHERE f1 = PADR("1",100)
 
 SET ANSI OFF
 SELECT * FROM test WHERE f1 = PADR("1",100)

А как он должен реагировать?

Цитата:
Ну, и заодно ;), почему такие странные результаты SYS(3054,1) в данных запросах? Т.е. Partial при SET ANSI ON и Full при SET ANSI OFF.

Я получаю None при SET ANSI OFF, потому что в данных условиях оптимизация не применяется.

Aleksey Tsingauz
Visual FoxPro Dev Team

Re: Зачем были созданы новые типы данных?
Владимир Максимов Автор Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000	Владимир Максимов 01.10.04 18:12:21 Алексей, спасибо. Игорь уже объяснил в чем я ошибался Думаю, данную тему можно закрыть. ------------------

Re: Зачем были созданы новые типы данных?
Zobr Сообщений: 73 Дата регистрации: 24.02.2004	Zobr 03.11.04 13:48:01 Aleksey Tsingauz [MSFT] писал(а): Цитата: ... В поле Char хранятся данные фиксированной длины равной размеру поля. В поле Varchar хранятся данные переменной длины не превышающей размер поля... Столкнулся со следующей проблемой: создал курсорадаптор связанный с таблицей; таблица содержит varchar поля; привязал textbox к полю курсорадаптора; если в поле курсора содержится null, то данные вводятся нормально, если, например, строка из 5 символов - то только в пределах этих 5-ти символов. К сожалению пример прислать не могу, очень уж непростой. Если можете подсказать направление поисков - буду очень благодарен.

Re: Зачем были созданы новые типы данных?

Zobr

Сообщений: 73
Дата регистрации: 24.02.2004

Zobr

03.11.04 13:48:01

Aleksey Tsingauz [MSFT] писал(а):

Цитата:
... В поле Char хранятся данные фиксированной длины равной размеру поля. В поле Varchar хранятся данные переменной длины не превышающей размер поля...

Столкнулся со следующей проблемой: создал курсорадаптор связанный с таблицей; таблица содержит varchar поля; привязал textbox к полю курсорадаптора; если в поле курсора содержится null, то данные вводятся нормально, если, например, строка из 5 символов - то только в пределах этих 5-ти символов.
К сожалению пример прислать не могу, очень уж непростой. Если можете подсказать направление поисков - буду очень благодарен.

Re: Зачем были созданы новые типы данных?
Владимир Максимов Автор Сообщений: 14097 Откуда: Москва Дата регистрации: 02.09.2000	Владимир Максимов 03.11.04 14:48:51 Попробуй забить в свойство TextBox.Format='XXXXXXXXXXXX' Столько символов "X", какая размерность поля. Ну, и проверь настройку TextBox.MaxLength Это глюк не столько типа данных, сколько автоопределения длины в объекте TextBox. ------------------

Re: Зачем были созданы новые типы данных?

Владимир Максимов
Автор

Сообщений: 14097
Откуда: Москва
Дата регистрации: 02.09.2000

Владимир Максимов

03.11.04 14:48:51

Попробуй забить в свойство

TextBox.Format='XXXXXXXXXXXX'

Столько символов "X", какая размерность поля. Ну, и проверь настройку TextBox.MaxLength

Это глюк не столько типа данных, сколько автоопределения длины в объекте TextBox.

------------------

Страницы: 1 2

:: Список Форумов•Список тем•Поиск•Войти

Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 28 (Гостей: 28)