DataSet.Locate nu este prietenos cu Filter, dar este necesar - cum să fie
Este foarte necesar
DataSet.Locate a căutat numai înregistrările care respectă DataSet.Filter
de exemplu, dacă conține DataSet
ID-ul # xA0; nume
---------
1 # xA0; name1
2 # xA0; nume2
3 # xA0; NAME3
4 # xA0; name1
5 # xA0; NAME3
după filtrare, rămâne
ID-ul # xA0; nume
---------
4 # xA0; name1
5 # xA0; NAME3
DataSet.Locate ("Nume", "Nume1", [loCaseInsensitive, loPartialKey])
găsește ID = 1 și trebuie să identifice = 4
Ce ar trebui să fac?
Însuși să treacă prin setul de date în căutarea înregistrării dorite.
Apropo, viteza în comparație cu Lokeyt practic nu se schimbă.
Utilizați TTable + Filter apoi totul va fi așa cum doriți.
În acest caz, pachetul va fi echivalent cu condiția filtru TQuery + din clauza unde se află. (Filtrarea pe server)
TQuery + Filter = filtrarea este întotdeauna pe client
Există:
# xA0; Tabelul "A" - de exemplu lucrătorii (IDRab, Name, Ot, Do)
# xA0; # xA0; # xA0; # xA0; # xA0; # xA0; # xA0; # xA0; # xA0; # xA0; Ot / Do - timpul de "vizibilitate" (dacă este disponibil)
# xA0; Tabelul "B" - de exemplu Comenzi (IDZak, IDRab, Ot, Do)
# xA0; Tabelul "C" - de exemplu ZakRab (IDZakRab, IDZak, IDRab, N)
Situația este următoarea:
# xA0; - deschide comanda cu o limită a timpului de execuție (de la - la) în LookupName alege numele
# xA0; # xA0; și atribuie [N] - aici este necesar ca în Lookup să fie doar cei care se potrivesc
# xA0; # xA0; Comanda [De la - la]. Folosesc filtrarea și totul funcționează cu un bang
# xA0; - WHERE - primul lucru pe care l-am încercat nu a fost potrivit dintr-un singur motiv,
# xA0; # xA0; înregistrările anterioare, în acest caz, în AfterScroll fac filtrarea (DataSet.Close / Open
# xA0; # xA0; funcționează neplăcut încet cu filtrul funcționează mai repede - dar are acest bug)
-> Treceți singur în setul de date în căutarea înregistrării dorite.
Apropo, viteza în comparație cu Lokeyt practic nu se schimbă.
Da, totul se face deja în DBGridEh - schimba-l. (
> Da, totul este deja făcut în DBGridEh - schimbați-l. (
Ei bine, bine. Toată speranța pentru unchiul care va face totul pentru tine?
Sau deja "toate" făcute în ExLibGrid. Apoi folosiți, ce vă cereți?
> Toți speranța pentru unchiu
Și de ce unchiul său - da, eu folosesc componente terțe părți (nu cred că orice ființă vie aici folosesc standardul actual VCL), în caz contrar s-ar fi scris pe ASM-e (din păcate, nu știu, dar cu această ocazie s-ar vyuchil)
# xA0; În general, DataSet.Filter este un instrument convenabil, cel puțin pentru mine, dar are o grămadă de "ieftin" - DataSet.Locate vede totul.
# XA0, și întrebarea mea a fost: Cum de a filtra DataSet pe client (de multe ori nu rula pe serverul de fiecare dată pentru date) și fără DataSet.Close / Open - din nou --- dar frânele trebuie să filtreze datele nebyli vizibile (pentru cel DataSet.Locate), deoarece la DBGridEh - am seichas favoarea așa uita la lista de ceea ce tip
PS. Nu cere / da, dar spune-mi
Încă nu înțeleg, dar cine este DataSet?
> Nu cred că cineva se bucură de standardul VCL curent
e de mirare tu, mulți oameni folosesc, îmi place. și numai standardul. (Știu biroul în care non-standard (/ nekuplennyh care de multe ori același lucru) sunt pur și simplu interzise. Avem o astfel de firmă. A fost. Așteptați nu este foarte atenție este acordată, dar nu din cauza ne mai ușoare a fost doar haos adăugat la creșterea biroului )
> altfel aș scrie pe ASM-e
Și de aceea? în sensul de a ști cu siguranță nu doare, dar ce legătură cu VCL?
> PS. Nu cere / da, dar spune-mi
cu ușurință. nu echivalați toți moștenitorii DataSet. dragoste specific (nu numai cu # xA0; DataSet). apoi evitați "o grămadă de preț ieftin". "
Este interesant faptul că filtrul este suprapus, că acest rezultat sa dovedit, că aici nu este curat.
de asemenea, interesat, verificat cu două tipuri diferite de seturi de date, ieșirea pentru filtru în încuietoare nu se încadrează, contrar sferelor afirmat.
Mă tem că vorbesc doar despre DataSet.Filter, dar de fapt folosesc onFilterRecord. (desi explica cumva afirmatia).
Probabil, dar e un partizan obișnuit.
Există o presupunere că prietenul folosește TIBDataSet. Dacă da, atunci nimic surprinzător - nu este filtrat deloc! Deoarece, așa cum se știe, în componentele IBX, proprietatea Filter nu este implementată.
Astfel:
DataSet -> ADO DataSet
ci pentru că a fost filtrat pentru filtrare. am scris
TDataSet (DataSet) .Filter: =. // și aici orice moștenitor va cădea
Mai departe.
# xA0; avem MasterDataSet, DetailDataSet în el câmpul Lookup1 de la SpravDataSet
În MasterDataSet există un grup de câmp (de exemplu - simplificat pentru un exemplu)
obiectiv:
# xA0; În Lookup1, câmpul DetailDataSet trebuie să aibă o listă incompletă a curentului lui SpravDataSet. corespunzătoare condiției (care se modifică cu fiecare tranziție la o altă intrare în MasterDataSet [MasterDataSet.AfterScroll])
Rezultat 1:
# xA0; WHERE - nu se potrivește cu SpravDataSet.Close / Open cu fiecare MasterDataSet.AfterScroll = frâne
Rezultat 2:
# xA0; în MasterDataSet.AfterScroll
# xA0; SpravDataSet.Filter: = Condiția filtrului
# xA0; -> totul funcționează pe uralele curentului este derutat de bug-ul de mai sus
PS. A început să se depaneze și a văzut că în DBGridEh când tastăm în câmpul Lookup, acesta este executat:
dacă AColumn.UsedLookupDataSet.Locate (AColumn.Field.LookupResultField, FSearchText,
# xA0; # xA0; # xA0; [loCaseInsensitive, loPartialKey]) apoi
aici este vărsat eroarea - SpravDataSet: Înregistrare nu a fost găsit
procedura TForm1.FormCreate (expeditor: TObject);
începe
# xA0; ADODataSet1.Open;
se încheie;
procedura TForm1.Edit1Change (expeditor: TObject);
începe
# xA0; dacă Edit1.Text <> „“ Atunci
# xA0; # xA0; ADODataSet1.Filter: = "ID" "+ Edit1.Text; // cifre curente cu siguranță :)
se încheie;
procedura TForm1.BitBtn1Click (expeditor: TObject);
începe
# xA0; ADODataSet1.Locate ("A", Edit2.Text, [loCaseInsensitive, loPartialKey]);
# xA0; ShowMessage ("ID =" + VarToStr (valoarea ADODataSet1.FieldByName ("ID").));
se încheie;
procedura TForm1.CheckBox1Click (expeditor: TObject);
începe
# xA0; ADODataSet1.Filtered: = CheckBox1.Checked;
se încheie;
Proba 1 (fără filtrare):
Tabelul 1. are forma:
ID-ul # xA0; A
--------
1 # xA0; aaa
2 # xA0; bbb
3 # xA0; ccc
4 # xA0; aaa
5 # xA0; bbb
ADODataSet1.Filtered: = False;
ADODataSet1.Locate ("A", "bb", [loCaseInsensitive, loPartialKey])
------
# xA0; ShowMessage ---> ID = 2 = DREAPTA
Proba 1 (cu filtrare):
Tabelul 1. are forma:
ID-ul # xA0; A
--------
4 # xA0; aaa
5 # xA0; bbb
ADODataSet1.Filtered: = False;
ADODataSet1.Filter: = "ID" 3 ";
ADODataSet1.Locate ("A", "bb", [loCaseInsensitive, loPartialKey]);
------
# xA0; ShowMessage ---> ID = 4 ---- NU DREPT - trebuie să fie ID = 5
De fapt, localizarea este o funcție logică. Dacă găsește, atunci adevărat
dacă ADODataSet1.Locate ("A", "bb", [loCaseInsensitive, loPartialKey])
atunci
# xA0; ShowMessage ("S-a găsit")
altfel
# xA0; ShowMessage ("nu este setat");
Nu voi dovedi, pot explica, sau mai degrabă. nu pentru nimic despre care v-a fost spus despre semnul egalității între seturile de date sau, mai degrabă, lipsa acestora. Verificați-l, repetați același lucru pe client (ClientDataSet) și încercați să obțineți același rezultat.
cu ADO-shnu și mai ușor, întreaga implementare a blocării în codul sursă în ADODB.LocateRecord, care dorește să înțeleagă de ce și cum funcționează, el va înțelege, oportunitatea este acolo.
nu este de acord cu soluția din Borland, folosiți metoda Find direct din obiect (metoda metodei mici) sau așa cum este sugerat în [1].
și apropo, filtrul fără Filtered = true (în [12] "Exemplul 1 (cu filtrare):") nu va funcționa.
> Vitaliy Panasenko # xA0; (25.07.06 18:09) [13]
Am pe linie dacă. eroarea renunță la "găsit" / "nu a găsit" și nu ajunge
dar în cursul nevoii, el trebuie - doar el trebuie să reziste și nu cel de-al doilea
> și, apropo, filtrul fără Filtered = true (în [12] "Exemplul 1 (s
> filtrare): ") nu va funcționa
=
Ochepyatka, desigur. Filtrați: = Adevărat
O altă considerație, în urma căreia presupunem că ar trebui să încercăm să expunem LookupCache în câmpul hardcod în DetailedDataSet.
Aceste povestitori (c)
TIBQuery într-adevăr nu funcționează, dar TIBTable, repet, funcționează bine cu filtrarea! Proiectul meu trăiește asupra lor!
Nu trebuie să încerc. E suficient să te uiți în surse.
> dar TIBTable, repet, e bine să faceți față filtrării!
Eu nu cred :)
Adu codul.
> Proiectul meu trăiește asupra lor!
Acesta este un miracol. Simt. Cu sinceritate. )
# xA0; dacă este Filtrată și (Filtrare <> "") # xA0;
# xA0; începeți
# xA0; # xA0; SQL.Text: = SQL.Text + "unde" + Filtru;
# xA0; # xA0; bWhereClausePresent: = Adevărat;
# xA0; sfârșitul;
Nu mă interesează codul sursă. Îmi place așa cum este.
Adu codul dvs. spunând că filtrul funcționează.
> Sunteți o bestie misterioasă. Și pentru a informa în mod specific ce eroare
> - un tabu?
> Nu mă interesează codul sursă. Îmi place să am ..
>.
Ei bine, uitați-vă cu atenție la el [22] și spuneți-mi de ce brusc nu funcționează
> Dați-vă codul spunând că filtrul funcționează
cât de interesant în cod puteți afla dacă a funcționat sau nu.
Ei bine, din moment ce sunteți atât de interesat, citez
# xA0; # xA0;
dmTable2.Table.Filter: = "Table1ID =" + dmTable1.fldID.AsString;
dmTable2.Table.Filtered: = true;
(numele obiectelor au fost modificate)
Eroarea este ridicată în procedura Resync cu parametrul mrExact
începe
# xA0; CursorPosChanged;
# xA0; dacă GetRecord (FBuffers [FRecordCount], gmCurrent, True) <> apoi OK
# xA0; # xA0; DatabaseError (SRecordNotFound, Self);
Aceasta înseamnă că nu se poate găsi o înregistrare pentru actualizarea / identificarea pentru obținerea unei valori de blocare. Bineînțeles, pentru că există un filtru. Prin urmare, încercați [16].
procedura TIBDataSet.SetFiltered (valoare: Boolean);
începe
# xA0; dacă (Filtrate <> Valoare) atunci
# xA0; începeți
# xA0; # xA0; setFiltered moștenit (valoare);
# xA0; # xA0; dacă este activă atunci
# xA0; # xA0; începeți
# xA0; # xA0; # xA0; Închidere;
# xA0; # xA0; # xA0; Deschis;
# xA0; # xA0; sfârșitul;
# xA0; sfârșitul
# xA0; altceva
# xA0; # xA0; setFiltered moștenit (valoare);
se încheie;
Și dacă da, această presupusă filtrare este o simplă modificare a textului cererii cu execuție repetată.
> NU LOCALIZAT, adică nu aveți o implementare locală pentru
> setul de date
ce înseamnă implementarea locală? IBTable este un set de date. Aceasta nu este o clasă abstractă.
> atunci această presupusă filtrare este o simplă modificare a textului interogării
> cu execuție repetată.
dar de ce aveți nevoie de filtrare normală? cum ar trebui să funcționeze?
Apropo, este necesar să se uite SetFilterText care este redefinit pentru TIBTable și se întinde de la predecesorul său - TDataSet.
Probabil pe client. Fără referința la server.
> ce înseamnă implementarea locală?
Acest lucru înseamnă pentru datele care sunt deja pe client, la nivel local.
> IBTable și există un set de date.
> # xA0; Aceasta nu este o clasă abstractă.
Despre clasa abstractă, nu am spus nimic.
> Și ce este necesar din filtrarea obișnuită?
Că a lucrat.
> Cum ar trebui să funcționeze?
> Așa e.
Ce dreptate? există un standard pentru filtrarea seturilor de date?
[16] - deja încercat - nu funcționează
Da, cred că Lookup nu are de a face cu ea, putem vedea din test că Locate caută DataSet în orice - nu ar trebui. Pentru mine, în nici un fel (local, nu WHERE) să-mi limitez căutarea unui curent pe înregistrări nefiltrate.
# xA0; Cum?
PS. Aș spune că aceasta este o eroare a funcției: De ce uitați dintr-o dată datele din afara câmpului vizual (pe marginea parametrului ar fi împins ca [loFullDataSet])
[39]
> Din test este vizibil faptul că localizează căutările pe toate în DataSet-e - în loc de
> ar trebui.
[15]
> Eu am pe linie dacă. eroarea renunță la "găsit" / "nu a găsit" și nu ajunge
Cum înțelegeți, domnule?
Trimiteți-le prietenilor: