:: Visual Foxpro, Foxpro for DOS
Сравнение полей таблиц Postgres без учёта конечных пробелов
Аркадий
Автор

Сообщений: 252
Откуда: Санкт-Петербург
Дата регистрации: 30.11.2005
Здравствуйте!

Подскажите, пожалуйста, кто использует Postgres, как надо выкручиваться из ситуации сравнения полей таблиц Postgres без учёта конечных пробелов.
Если там есть кодовое поле, например, varchar(10) и данные в нём хранятся без конечных пробелов, то при использовании для него в фоксе курсорадаптера с типом С(10) после создания записи в дочерней таблице с этим кодом, оно дополняется пробелами.
Как сказали на форуме
www.sql.ru
у них, в отличие от SQL Server или VFP, нет настроек для сравнения строк без учёта конечных пробелов.
Это кодовые поля, по ним есть индексы, не хотелось бы применять к ним функции без особой надобности.
Ratings: 0 negative/0 positive
Re: Сравнение полей таблиц Postgres без учёта конечных пробелов
ssa

Сообщений: 13008
Откуда: Москва
Дата регистрации: 23.03.2005
1.
Аркадий
varchar(10) и данные в нём хранятся без конечных пробелов, то при использовании для него в фоксе курсорадаптера с типом С(10)
Что мешает использовать V(10)?
2. В курсорадаптере есть свойство ConversionFunc, которое, например, у меня у первой попавшейся таблицы выглядит так:
ID_ADETTO RTRIM,ID_VENDITORE RTRIM,NATO This.DtoNull
и для указанных полей запускает соответствующие функции, в том числе и самописные.


------------------
Лень - это неосознанная мудрость.




Исправлено 1 раз(а). Последнее : ssa, 25.12.18 12:32
Ratings: 0 negative/0 positive
Re: Сравнение полей таблиц Postgres без учёта конечных пробелов
leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006
Аркадий
Если там есть кодовое поле, например, varchar(10) и данные в нём хранятся без конечных пробелов

А Вы могли бы привести хотя бы один пример, когда бы на Postgres два значения совпадали, а на фоксе в С(10) - нет. Ну, или наоборот.
Ratings: 0 negative/0 positive
Re: Сравнение полей таблиц Postgres без учёта конечных пробелов
Аркадий
Автор

Сообщений: 252
Откуда: Санкт-Петербург
Дата регистрации: 30.11.2005
ssa
Что мешает использовать V(10)?
2. В курсорадаптере есть свойство ConversionFunc, которое, например, у меня у первой попавшейся таблицы выглядит так:
ID_ADETTO RTRIM,ID_VENDITORE RTRIM,NATO This.DtoNull
и для указанных полей запускает соответствующие функции, в том числе и самописные.
Не пришло в голову, надо попробовать.

leonid
А Вы могли бы привести хотя бы один пример, когда бы на Postgres два значения совпадали, а на фоксе в С(10) - нет. Ну, или наоборот.
Когда я записываю поле varchar(10) без конечных пробелов из Postgres в КА, то в КА появляются конечные пробелы. В SQL Server это не имело значения, а в Postgres после сохранения такого поля в другую таблицу, они уже не совпадают, и в SELECT в Postgres соответствия не будет.
Было 'aa', после сохранения через КА в другую таблицу на Postgres в ней стало 'aa ' (что-то здесь пробелы в кавычках не отображаются). При одинаковом типе полей varchar(10) в таблицах запрос на Postgres не выполнится.
Ratings: 0 negative/0 positive
Re: Сравнение полей таблиц Postgres без учёта конечных пробелов
Аркадий
Автор

Сообщений: 252
Откуда: Санкт-Петербург
Дата регистрации: 30.11.2005
Свойство ConversionFunc крайне помогло. Осталась вероятная проблема, что в Postgres попадётся ключевое поле с конечным пробелом. Если это случится, возможно ли отловить и в точности записать в другую табличку?
Ratings: 0 negative/0 positive
Re: Сравнение полей таблиц Postgres без учёта конечных пробелов
ssa

Сообщений: 13008
Откуда: Москва
Дата регистрации: 23.03.2005
Аркадий
Свойство ConversionFunc крайне помогло. Осталась вероятная проблема, что в Postgres попадётся ключевое поле с конечным пробелом. Если это случится, возможно ли отловить и в точности записать в другую табличку?
А может проблемы решать мере их поступления?

------------------
Лень - это неосознанная мудрость.
Ratings: 0 negative/0 positive
Re: Сравнение полей таблиц Postgres без учёта конечных пробелов
leonid

Сообщений: 3204
Откуда: Рига
Дата регистрации: 03.02.2006
Аркадий
Postgres попадётся ключевое поле с конечным пробелом.

Если у Вас все коды имеют одинаковую длину, то сделайте в фоксе поле С(длина кода) и на этом успокойтесь. Фокс ничего лишнего никуда не запишет. Если же коды могут иметь разную длину, то меня просто умиляет Ваша радость по поводу того, что SQL Server умеет сравнивать без конечных пробелов такие, например, коды, как 'a'+space(1) и 'a'+space(2).
Ratings: 0 negative/0 positive
Re: Сравнение полей таблиц Postgres без учёта конечных пробелов
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Если уж используете символьные ключевые поля, то сделай их фиксированного размера на сервере и всё. не varchar а char. И уже без разницы будет кто и как туда записывет данные - сервер сам дополнит пробелами до фиксированного размера и будет сравнивать все 10 или сколько там задано символов. Конечно это не спасёт от корявых клиентов которые пропихнут ведущие пробелы в такое поле - ну да то уж не твоя проблема будет. Ну это если разработчик настолько безумен что прямо в интерфейсе позволяет не только смотреть, но и вводить значения для ключевых полей

Хотя как по мне, то символьные ключевые поля - само по себе порочная практика.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Сравнение полей таблиц Postgres без учёта конечных пробелов
Аркадий
Автор

Сообщений: 252
Откуда: Санкт-Петербург
Дата регистрации: 30.11.2005
leonid
Если у Вас все коды имеют одинаковую длину, то сделайте в фоксе поле С(длина кода) и на этом успокойтесь. Фокс ничего лишнего никуда не запишет. Если же коды могут иметь разную длину, то меня просто умиляет Ваша радость по поводу того, что SQL Server умеет сравнивать без конечных пробелов такие, например, коды, как 'a'+space(1) и 'a'+space(2).
Коды на Postgres имеют одинаковую длину, но фокс записывает взятый из одной таблицы Postgres код, который там хранится без пробелов в другую дочернюю таблицу на Postgres уже с пробелами. Как раз поле С(длина кода) с нелишними для фокса пробелами этим у меня и занимается. Кроме того, иногда надо искать не по коду.

Конечно, коды вручную никто не вводит, но приходится работать с федеральными справочниками, в которых код - символьное поле. Да и все прочие разработчики везде коды уже насоздавали varchar, и переделать во всех табличках и программах тип кода уже не представляется возможным. Это не всегда первичный ключ, иногда надо же иметь ключевым что-нибудь смысловое символьное.

Давно забытое свойство ConversionFunc пока решает проблемы.
Ratings: 0 negative/0 positive


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

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

© 2000-2024 Fox Club 
Яндекс.Метрика