ADOTable.Filter и float значения

← →
George © (2010-11-30 09:23) [0]

Вот интересно. Есть поле в таблице содержащее числа с плавающей запятой. Есть ADOTable (/ADODataSet/ADOQuery - не суть важно). Ввожу в Edit что-то вроде 4,2 например. Теперь мне надо, чтобы сработал фильтр у датасета:
TariffsADOTable.Filtered := false; TariffsADOTable.Filter := "(CatID = 1) and " + "(MinValue <= " + FloatToStr(LDMVal) + ") and " + "(MaxValue >= " + FloatToStr(LDMVal) + ")"; TariffsADOTable.Filtered := true;
Так в результате фильтр не работает, потому что видимо запятая там мешает. Как обойти? Можно конечно данные доставать не с помощью фильтра, а запросец делать, но не хочется.

← →
И. Павел © (2010-11-30 10:02) [1]

Обычно фильтрами не пользуюсь (и уж тем более TADOTable), но может быть там просто другой разделитель, а не тот, который установлен в региональных настройках локальной машины?

← →
sniknik © (2010-11-30 10:12) [2]

> а не тот, который установлен в региональных настройках локальной машины?
в запросах на них плюют, т.к. запятая зарезервирована за перечислением.

← →
Inovet © (2010-11-30 10:15) [3]

> [0] George © (30.11.10 09:23)
> FloatToStr(LDMVal)

Попробуй хотябы
FormatFloat

А почему нехочется запрос?

> [0] George © (30.11.10 09:23)
> Можно конечно данные доставать не с помощью фильтра, а запросец
> делать, но не хочется.

← →
George © (2010-11-30 10:27) [4]

> А почему нехочется запрос?

Да че та лень. :)

← →
Inovet © (2010-11-30 10:28) [5]

> [4] George © (30.11.10 10:27)
> Да че та лень. :)

А, ну это уважительная причина.

← →
И. Павел © (2010-11-30 10:37) [6]

> Да че та лень.

Ну хоть честно ответил, а не стал заливать про необходимость в этой задаче TTable и локальной фильтрации :)

← →
George © (2010-11-30 11:01) [7]

Переделал фильтрацию на запросы. Лень ленью, а куда деваться, коли фильтр тупой. :)

← →
sniknik © (2010-11-30 11:08) [8]

> коли фильтр тупой. :)
можно поспорить, кто, и если выбирать между документированным фильтром, и программистом не сумевшим в нем разобраться... выбор очевиден.

← →
George © (2010-11-30 11:19) [9]

> sniknik © (30.11.10 11:08) [8]

Во-первых, я могу Вам выложить справку (у меня Delphi 2010), где ни слова о фильтрации по числам с плавающей запятой. Во-вторых, если Вы считаете нормальным, логичным и хорошим подходом то, что оно таки не документировано, и еще и сделано хрен знает как (могли быть хоть параметры предусмотреть, как для SQL запросов), то мне даже не о чем с Вами спорить. У компонента тоже должно быть некое юзабилити для использования оного программистом.

← →
Ega23 © (2010-11-30 11:37) [10]

> У компонента тоже должно быть некое юзабилити для использования
> оного программистом.

Юзабилити у TTable?!?!?!?
Вы делаете мне смеяться.

← →
sniknik © (2010-11-30 11:40) [11]

> у меня Delphi 2010
а дельфи тут не причем. это не язык дельфи, это внешнее. т.е. даже если нету, то все одно не обязаны.

> где ни слова о фильтрации по числам с плавающей запятой.
такой нет, и не может быть. а вот про сам метод/переменную Filter, ее правила/особенности, другое дело.

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

← →
sniknik © (2010-11-30 11:42) [12]

> Юзабилити у TTable?!?!?!?
он упоминал и ADODataSet, надежда есть, иначе не стоило бы и пытаться.

← →
Anatoly Podgoretsky © (2010-11-30 11:49) [13]

> George (30.11.2010 11:01:07) [7]

Так ли это

← →
George © (2010-11-30 11:53) [14]

> sniknik © (30.11.10 11:42) [12]

Речь шла о концепции фильтра. Насколько я знаю, оно одинаково работает что у TADOTable, что у TADOQuery, что у TADODataSet.

> а дельфи тут не причем. это не язык дельфи, это внешнее.
> т.е. даже если нету, то все одно не обязаны.

Я говорю про справку, идущую в комплекте с Delphi 2010. Возможно это есть в справке к Delphi 7, но к 2010-ому нету.

> такой нет, и не может быть. а вот про сам метод/переменную
> Filter, ее правила/особенности, другое дело.

Конечно. Есть. Но все либо про строки, либо про целые числа. Вроде про даты тоже че то было. Но все не то - не мой случай.

> оно есть, и оно весьма простое. (не, есть и особенности,
> но не в этом случае).

Ну таки недостаточное, как мне видится.

← →
Ega23 © (2010-11-30 11:56) [15]

> Вроде про даты тоже че то было.

unit System; .... TDateTime = type Double;

З.Ы. С фильтрами не работал принципиально.

← →
George © (2010-11-30 11:56) [16]

> Anatoly Podgoretsky © (30.11.10 11:49) [13]

Ну мое скромное мнение, что да. Я бы предусмотрел удобную фильтрацию по основным типам данных - строкам, целым числам, числам с плавающей запятой, датам и логическим типам. Что мешало сделать параметры для фильтрации?

← →
George © (2010-11-30 11:58) [17]

> Ega23 © (30.11.10 11:56) [15]

А так таки вру. Глянул - про даты тоже тишина.

> З.Ы. С фильтрами не работал принципиально.

Канешно. Они тупые потому что. И малоюзабельные.

← →
Ega23 © (2010-11-30 12:03) [18]

> Канешно. Они тупые потому что. И малоюзабельные.

Не в этом дело. Они как панацея для идиётов придумана, которые делают Select * или TTable используют, тащат на клиент всю огромную выборку, а потом начинают её фильтровать.

← →
sniknik © (2010-11-30 12:05) [19]

> Речь шла о концепции фильтра.
а концепция использования ADOTable/ADOQuery подразумевает что использующий их ламер... по первому в большей степени.

> Ну таки недостаточное, как мне видится.
ну ну
скопировано (без форматирования) пример есть буквально для всего

Filter Property
Indicates a filter for data in a Recordset.

Settings and Return Values
Sets or returns a Variant value, which can contain one of the following:

Criteria string — a string made up of one or more individual clauses concatenated with AND or OR operators.
Array of bookmarks — an array of unique bookmark values that point to records in the Recordset object.
A FilterGroupEnum value.
Remarks
Use the Filter property to selectively screen out records in a Recordset object. The filtered Recordset becomes the current cursor. Other properties that return values based on the current cursor are affected, such as AbsolutePosition, AbsolutePage, RecordCount, and PageCount. This is because setting the Filter property to a specific value will move the current record to the first record that satisfies the new value.

The criteria string is made up of clauses in the form FieldName-Operator-Value (for example, "LastName = "Smith""). You can create compound clauses by concatenating individual clauses with AND (for example, "LastName = "Smith" AND FirstName = "John"") or OR (for example, "LastName = "Smith" OR LastName = "Jones""). Use the following guidelines for criteria strings:

FieldName must be a valid field name from the Recordset. If the field name contains spaces, you must enclose the name in square brackets.
Operator must be one of the following: <, >, <=, >=, <>, =, or LIKE.
Value is the value with which you will compare the field values (for example, "Smith", #8/24/95#, 12.345, or $50.00). Use single quotes with strings and pound signs (#) with dates. For numbers, you can use decimal points, dollar signs, and scientific notation. If Operator is LIKE, Value can use wildcards. Only the asterisk (*) and percent sign (%) wild cards are allowed, and they must be the last character in the string. Value cannot be null.
Note To include single quotation marks (") in the filter Value, use two single quotation marks to represent one. For example, to filter on O"Malley, the criteria string should be "col1 = "O""Malley"". To include single quotation marks at both the beginning and the end of the filter value, enclose the string with pound signs (#). For example, to filter on "1", the criteria string should be "col1 = #"1"#".
There is no precedence between AND and OR. Clauses can be grouped within parentheses. However, you cannot group clauses joined by an OR and then join the group to another clause with an AND, like this:
(LastName = "Smith" OR LastName = "Jones") AND FirstName = "John"
Instead, you would construct this filter as
(LastName = "Smith" AND FirstName = "John") OR (LastName = "Jones" AND FirstName = "John")
In a LIKE clause, you can use a wildcard at the beginning and end of the pattern (for example, LastName Like "*mit*"), or only at the end of the pattern (for example, LastName Like "Smit*").
The filter constants make it easier to resolve individual record conflicts during batch update mode by allowing you to view, for example, only those records that were affected during the last UpdateBatch method call.

Setting the Filter property itself may fail because of a conflict with the underlying data (for example, a record has already been deleted by another user). In such a case, the provider returns warnings to the Errors collection but does not halt program execution. A run-time error occurs only if there are conflicts on all the requested records. Use the Status property to locate records with conflicts.

Setting the Filter property to a zero-length string ("") has the same effect as using the adFilterNone constant.

Whenever the Filter property is set, the current record position moves to the first record in the filtered subset of records in the Recordset. Similarly, when the Filter property is cleared, the current record position moves to the first record in the Recordset.

See the Bookmark property for an explanation of bookmark values from which you can build an array to use with the Filter property.

Only Filters in the form of Criteria Strings (e.g. OrderDate > "12/31/1999") affect the contents of a persisted Recordset. Filters created with an Array of Bookmarks or using a value from the FilterGroupEnum will not affect the contents of the persisted Recordset. These rules apply to Recordsets created with either client-side or server-side cursors.

Note When you apply the adFilterPendingRecords flag to a filtered and modified Recordset in the batch update mode, the resultant Recordset is empty if the filtering was based on the key field of a single-keyed table and the modification was made on the key field values. The resultant Recordset will be non-empty if one of the following is true:
The filtering was based on non-key fields in a single-keyed table.
The filtering was based on any fields in a multiple-keyed table.
Modifications were made on non-key fields in a single-keyed table.
Modifications were made on any fields in a multiple-keyed table.
The following table summarizes the effects of adFilterPendingRecords in different combinations of filtering and modifications. The left column shows the possible modifications; modifications can be made on any of the non-keyed fields, on the key field in a single-keyed table, or on any of the key fields in a multiple-keyed table. The top row shows the filtering criterion; filtering can be based on any of the non-keyed fields, the key field in a single-keyed table, or any of the key fields in a multiple-keyed table. The intersecting cells show the results: + means that applying adFilterPendingRecords results in a non-empty Recordset; - means an empty Recordset.
Non keys Single Key Multiple Keys
Non keys + + +
Single Key + - N/A
Multiple Keys + N/A +

← →
sniknik © (2010-11-30 12:06) [20]

> А так таки вру. Глянул - про даты тоже тишина.
именно что врешь. про даты тоже.

← →
Anatoly Podgoretsky © (2010-11-30 12:21) [21]

> Что мешало сделать параметры для фильтрации?

С этой претензией не к Embarcadero а ко всем производителям всех СУБД.

← →
Anatoly Podgoretsky © (2010-11-30 12:24) [22]

> George (30.11.2010 11:58:17) [17]

Так и есть, а что тебя то заставило, тем более что знаешь?

← →
George © (2010-11-30 12:31) [23]

> Anatoly Podgoretsky © (30.11.10 12:24) [22]

Так я и говорю - лень. Хотелось сделать тупо, просто и быстро. Не вышло.

> Anatoly Podgoretsky © (30.11.10 12:21) [21]

А разве ж фильтры не с локальным набором данных работают?

> а концепция использования ADOTable/ADOQuery подразумевает что
> использующий их ламер... по первому в большей степени.
Это уход от темы. Я мог с тем же успехом ADODataSet использовать. Речь о фильтре.

> sniknik © (30.11.10 12:05) [19]

А я зря что-ли студию упомянул?

Description

Specifies the text of the current filter for a dataset.

Use Filter to specify a dataset filter. When filtering is applied to a dataset, only those records that meet a filter"s conditions are available. Filter describes the filter condition. For example, the following filter condition displays only those records where the State field is "CA" or "MA":

State = "CA" or State = "MA"

When a filter is set, Blank records do not appear unless explicitly included in the filter. For example:

State <> "CA" or State = NULL

When a field name contains spaces, you must enclose the field name in brackets. For example:

[Home State] = "CA" or [Home State] = "MA"

Filter expressions on remote SQL tables and on client datasets support field comparisons. For example:

Field1 > Field2

Field comparisons are not supported against local tables (Paradox, dBASE, Access, FoxPro).

For a complete list of operators you can use in filter strings, see SettingTheFilterProperty.

Note: Filters are not supported on unidirectional datasets. If you set the Filter property of a unidirectional dataset, it raises an exception.
The FilterOptions property controls case sensitivity and filtering on partial comparisons.

Tip: Applications can set Filter at runtime to change the dataset"s filtering condition (for example, in response to user input).

← →
Anatoly Podgoretsky © (2010-11-30 13:12) [24]

> George (30.11.2010 12:31:23) [23]

С локальным, но в Дельфи нет своей поддержки СУБД, это делается средствами
других библиотек, поэтому и форматы фильтров зависят от СУБД, для dBase
одно, для Акцесс другое.

← →
George © (2010-11-30 13:24) [25]

> Anatoly Podgoretsky © (30.11.10 13:12) [24]

Теперь ясно все.

← →
sniknik © (2010-11-30 14:06) [26]

> А я зря что-ли студию упомянул?
а справку приводишь для BDE locale.

> sniknik © (30.11.10 14:06) [26]

Что Вы имеете ввиду под BDE locale?
Это справка по TDataSet.Filter, выводится по нажатии F1 в студии в редакторе кода.

то что это справка от BDE. хотя с локале ошибся, хотел написать найтиве :(

> выводится по нажатии F1 в студии в редакторе кода.
> у меня Delphi 2010
Ю а дельфи тут не причем. это не язык дельфи, это внешнее. т.е. даже если нету, то все одно не обязаны.
после этого ты должен был бы "забить" на эту справку, а не приводить ее в пример через 15 постов.

Вот именно, что по TDataSet.Filter, а не по TCustomADODataSet.Filter
Их же минимум 5 этих Filter

> Anatoly Podgoretsky © (30.11.10 14:28) [29]

В той же справке у меня сказано, что у TADODataSet свойство Filter унаследовано от TDataSet.

> sniknik © (30.11.10 14:26) [28]

Да я понимаю все. Просто Вы сказали, что сие хорошо задокументировано, вот я и придрался. Справка же идет в комплекте со студией, так вот в той, что у меня, не задокументировано ничего по поводу фильтрации по датам и по числам с плавающей запятой. А в гугле не нашел, хотя и допускаю, что не смог составить кошерную ключевую фразу.

> George (30.11.2010 14:51:30) [30]

Ну и что, справка разная для этих датасет.
Да и само свойство не выполняет никаких действий, оно же string, выполняют
сеттеры

> Anatoly Podgoretsky (30.11.2010 14:57:31) [31]

Или вообще перекрыты, какие либо внутренние функции. Это надо генофонд
смотреть.

> что сие хорошо задокументировано
а разве плохо? см. мою выдержку. просто смотреть нужно не там "где светлее", а у того с чем работаешь.

Нельзя сравнивать никакие плавающие БД-поля посредством тупого "=" или ">" / "<". Только после округления и только в диапазоне. Это как бы априори должно быть понятно.
Это все равно что писать пи=3.14 :)

Использование фильтров заимствовано из старых "локальных" СУБД и в подавляющем большинстве случаев является следствием "привычек" программистов и никоим образом не диктуется условиями задачи.

Фильтрацию следует выполнять модифицируя текст запроса и переоткрывая датасет. Т.е. "чистым" сиквелем. Это позволит "избавиться" от "ошибок" оболочки (в данном случае реализации фильтов в TdataSet (если таковые имеются - сам давно не использую), перейдя на общение с сервером на его языке.

> Фильтрацию следует выполнять модифицируя текст запроса и переоткрывая датасет.
бред и порочная практика.
получение данных нужно делать запросом, а фильтровать полученное, если нужно, то это фильтром.
смешивать понятия не рекомендуется. имхо, это такой же ламеризм как и в случае использования - таблица + фильтр в клиент серверном приложении, только с другим знаком.

> sniknik © (30.11.10 21:45) [35]

> получение данных нужно делать запросом, а фильтровать полученное,
> если нужно, то это фильтром.

- Я буду обедать в столовой, а оперировать в операционной!

--
Regards, LVT.

ADOTable.Filter и float значения Найти похожие ветки