SQL изразът е съкратен и отхвърлен като грешка

Приложете следния SQL оператор към ClientDataset като свойство Filter:

'(((DORcode > ''00'') AND (DORcode < ''10'')) AND (((SiteNumber+'' ''+SiteStreet+SiteCity)<>(OwnerAddr1+OwnerCity)) AND ((SiteNumber+SiteStreet+SiteCity)<>(OwnerAddr1+OwnerCity))) AND (TaxStatus > ''!''))'

Дава ми следната грешка: „)“ се очаква, но нищо не е намерено или (за >още по-дълъг израз): Несъответствие на типа.

Гмуркането в детайлите установи, че проблемът е причинен от дължината на изявлението, части от него работят, като:

'(((DORcode > ''00'') AND (DORcode < ''10'')) AND (((SiteNumber+'' ''+SiteStreet+SiteCity)<>(OwnerAddr1+OwnerCity))))';

или всяка друга по-къса част.

Всички имена на полета са валидни, наборът от данни не е празен, филтрите работят добре за всички включени имена на полета, ако изразът е по-кратък.

Така че грешката не е синтактична, явно е причинена от вътрешно изрязване на оператора, надвишаващо ограничението за брой символи (някъде между 111 и 196).

Въпросите ми са: 1. Някой забелязвал ли е тази грешка на Delphi XE5? 2. Пач ли е за него? 3. Как да решим филтрирането за първоначалния (дълъг) оператор по друг начин?

Благодаря ви предварително.


person Laszlo    schedule 09.03.2015    source източник
comment
Не съм сигурен какъв е проблемът, но можете ли да използвате OnFilterRecord като заобиколно решение?   -  person David Dubois    schedule 09.03.2015
comment
По-добре казано, трябва да използвате OnFilterRecord за такава бъркотия с низове.   -  person TLama    schedule 09.03.2015
comment
@AD7six Защо питаш това, каква е причината ти?   -  person Laszlo    schedule 09.03.2015
comment
Защото писането с ГЛАВНИ БУКВИ е по-трудно за четене и няма причина да КРЕЩЕТЕ на нас тук. Причината, поради която има клавиши Shift от двете страни на клавиатурата, е да бъдат лесни за достигане, тъй като текстът с правилни главни букви е по-лесен за четене и разбиране. Въвеждането само с ГЛАВНИ букви няма да ви осигури по-бърз отговор и е доста грубо да КРЕЩИТЕ на хората, които молите за безплатна помощ, за да разрешите проблема си.   -  person Ken White    schedule 09.03.2015
comment
@Ken Използвам главни букви, за да подчертая нещо, а не да крещя. Просто се страхувах, че някой ще се опита да намери грешката в тези посоки. Ако сте приели това като викане, извинете тогава.   -  person Laszlo    schedule 09.03.2015
comment
Подходящият начин да подчертаете нещо е да го направите удебелено не само с главни букви.   -  person Jerry Dodge    schedule 09.03.2015
comment
@Jerry Благодаря за всички стилове, които помагат :). Наистина ще се радвам, ако някой ми помогне в истинския проблем.   -  person Laszlo    schedule 09.03.2015
comment
Изглежда вече имате два отговора по-долу.   -  person Jerry Dodge    schedule 09.03.2015


Отговори (2)


Не мога да коментирам дали има грешка с XE5, но забелязвам, че имате цял куп ненужни скоби във филтъра. Мисля, че следното би било валидно и може би по-ясно, макар че без да знам всичките ви типове данни, не съм 100% сигурен.

DORcode > '00' AND 
DORcode < '10' AND 
SiteNumber + ' ' + SiteStreet + SiteCity <> OwnerAddr1 + OwnerCity AND
SiteNumber + SiteStreet + SiteCity <> OwnerAddr1 + OwnerCity AND 
TaxStatus > '!'

Освен това - бих обмислил изграждането на филтъра по този начин, защото мисля, че ще бъде по-ясно

FilterString := 'DORcode > 0 AND DORcode < 10 AND ' +
                'Trim(SiteNumber) + Trim(SiteStreet) + SiteCity <> ' +
                '     OwnerAddr1 + OwnerCity AND ' +
                'TaxStatus > ''!''';

Това полезно ли е?

person Hugh Jones    schedule 09.03.2015
comment
Благодаря Ви за отговора. Прав си, наясно съм, че има много излишни скоби (поставете ги само за четливост), но това не трябва да е причината за грешката (всъщност не е, защото работят на по-къси филтри). Опитах вашия вариант, но компилаторът очевидно ми дава грешка на неизвестна променлива за имената на полетата, съдържащи се в командата Format. От друга страна не разбирам каква ще е разликата, тъй като Format ще генерира точно същия низ, както съм написал, и същото изявление ще бъде прехвърлено към SQL анализатора, което дава грешката? - person Laszlo; 09.03.2015
comment
Не знам за никакъв проблем по отношение на дължината на филтърния низ, но ако кажете, че това е проблемът, тогава го съкратете. Виждам, че съм прочел неправилно имената на полетата като променливи - ще редактирам това. Каква RDBMS използвате btw? - person Hugh Jones; 09.03.2015
comment
Благодаря ви, но все още не ми помага. Последното ви (по-кратко) твърдение работи, но не е логически еквивалентно на моя оригинал. Опитах се да вмъкна символи за подаване на ред и връщане на каретка, но Delphi изглежда ги игнорира в това свойство на филтъра. Наистина не знам какво да правя. - person Laszlo; 09.03.2015
comment
не би трябвало да е нужно много, за да разберете правилната логика. Кавичките около 00 и 10 ли са? както казах - без да виждам вашите данни, предполагам каква трябва да бъде правилната форма - person Hugh Jones; 09.03.2015
comment
Отново синтаксисът е добър. Всички мои данни са в низова форма. Всяка част от изявлението ми работи добре поотделно. Проблемът възниква само когато изразът е по-дълъг от прибл. 120 знака. Търся помощ относно това странно вътрешно изрязване на филтърния низ. Някой забелязва ли го, има ли обяснение, тренировка? - person Laszlo; 09.03.2015
comment
Може да даде по-добър пример за това колко странно е поведението на свойството Filter: Ако приложите филтър (135 знака), резултатът е правилен (389 898 записа). Ако свържа същия филтър два пъти (с И, което очевидно трябва да даде СЪЩИЯ резултат, той все още работи, но получавам грешен резултат (527 470 записа). Ако свържа същия< /b> филтрира три пъти (с две И), което също трябва да даде СЪЩИЯ резултат, не работи, дава съобщение за грешка: ')' очаквано, но намерено... Може би сега е ясно какъв е проблемът ми. - person Laszlo; 10.03.2015
comment
Изразът на филтъра е: '(((SiteNumber+'' ''+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity)) И ((SiteNumber+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity)))' съответно (взети два пъти ): '(((SiteNumber+'' ''+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity)) И ((SiteNumber+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity))) И '+ '(((SiteNumber+ '' ''+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity)) И ((SiteNumber+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity)))' и взети три пъти: вижте следващия коментар - person Laszlo; 10.03.2015
comment
'(((SiteNumber+'' ''+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity)) И ((SiteNumber+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity))) И '+ '(((SiteNumber+'' ''+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity)) И ((SiteNumber+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity))) И '+ '(((SiteNumber+'' ''+SiteStreet+SiteCity) ‹›(OwnerAddr1+OwnerCity)) И ((SiteNumber+SiteStreet+SiteCity)‹›(OwnerAddr1+OwnerCity)))' - person Laszlo; 10.03.2015
comment
@laszlo - ако откажете да опростите, тогава не мога да ви помогна. съжалявам - person Hugh Jones; 11.03.2015
comment
Благодаря ви за доброто намерение. Не отказвам да опростя, но според мен не е възможно. Изявлението вече е в минималната си форма. Всяка промяна ще промени логиката му. Ако трябваше да е възможно, никога не идвах тук за помощ. Всъщност бих могъл да заобиколя целия проблем, като включа допълнителен набор от данни и направя каскадно (вложено) филтриране. Въпреки това съм много разстроен от този неочакван бъг в Delphi, а също и изненадан, че никой не го е забелязал досега и, изглежда, никой дори не се интересува от него. Момчетата от Embarcadero четат ли някога тези страници? - person Laszlo; 11.03.2015
comment
ако това наистина е грешка, тогава трябва да можете да съставите проста, обща примерна програма, за да я възпроизведете. Ако направите това, вие сте в състояние да го повдигнете като грешка с Emba и тя ще бъде поправена. Вашият въпрос в настоящата му форма пропуска твърде много контекст, за да убеди всеки, че сте открили грешка. Късмет - person Hugh Jones; 12.03.2015

Моля, имайте предвид типовете данни. В преформатиран пример 1 DORcor изглежда като низ, в пример 2 той е кодиран като число. Можете също така да комбинирате Sitenumber (което звучи като число) със Sitestreet, което звучи по-скоро като низ.

person Christine Ross    schedule 09.03.2015
comment
Здравей Кристин, благодаря ти за наблюденията, но ти не обърна внимание на моето описание на проблема. Подчертах (с главни букви), че всички части на изявлението са добри и проверени, работят добре. Всъщност всичките ми полета са тип низ, дори и да представляват числа. Причината за грешка тук не е лошият синтаксис. Благодаря все пак. - person Laszlo; 09.03.2015
comment
Съжалявам, но много добре обърнах внимание на проблема ти. Вашето първо съобщение за грешка съдържа несъответствие на типа. Както споменахме по-горе, SQL изразът е предимно широк низ, който трябва да може да съдържа много повече от 200 знака. - person Christine Ross; 09.03.2015
comment
Съобщението за грешка зависи от това къде системата изрязва оригиналното (добро!!!!) изявление. Въпреки изричните ми грижи да избягвам този тип отговори, вие се опитвате да намерите синтактични грешки в изявлението ми. Пробвах всяка част поотделно, всички работят добре. Съгласен съм с вас, че филтърният низ е широк и трябва да съдържа много повече от 200 знака, но НЕ Е!!! Подстригва се от системата, не можах да разбера къде и защо. Можете да го изпробвате лесно и на вашата система с фиктивна заявка. Точно това е моят проблем и чакам помощ от някой, който може да реши ТОЗИ. - person Laszlo; 09.03.2015
comment
@Christine - Както го прочетох - това не е Sql израз, а филтър на TClientDataset - person Hugh Jones; 10.03.2015