_tally lügt
tom knauf
ich habe hier ein sehr exotisches Problem, vielleicht hat jemand einen Tip
f�r mich :
Auf einer gro�en SQL-Tabelle (Tabelle1) liegt u.a. eine parametrisierte
Remoteview (rv_tabelle1)
Hier noch ein paar Einstellungen :
DBSetProp(ThisView,"View","FetchAsNeeded",.F.)
DBSetProp(ThisView,"View","FetchMemo",.T.)
DBSetProp(ThisView,"View","FetchSize",-1)
DBSetProp(ThisView,"View","MaxRecords",-1)
DBSetProp(ThisView,"View","Prepared",.F.)
DBSetProp(ThisView,"View","ShareConnection",.T.)
DBSetProp(ThisView,"View","AllowSimultaneousFetch",.F.)
rv_tabelle ist nicht ge�ffnet (kein Use) und wird direkt abgefragt mit :
Select * from daten1!rv_tabelle1 where nachname= 'TOM' into array antest
If _tally
.....
Der Effekt :
_tally zeigt 1, obwohl in rv_tabelle1 bei den Parameterwerten keine Daten
enthalten sein k�nnen,
debugge ich das zeigt _tally zun�chst 1, nach ca. 30s dann den korrekten
Wert 0.
_tally = 0 vorab bringt leider nix.
Wo ist da mein Denkfehler ?
Vielen Dank f�r Eure Hilfe
Tom
Olaf Doschke
reccount("Alias"). Da wei� man, was man hat, insbesondere bei alias =
cursoralias einer Abfrage ohne DELETED Datens�tze nat�rlich.
Dir sollte klar sein, da� ein SELECT ... FROM viewname ein SELECT auf einen
SELECT ist und das Dir in die Suppe spucken k�nnte. Erstz das doch mal durch
USE rv_tabelle1 IN 0 NODATA
viewparameter = "TOM"
REQUERY("rv_tabelle1")
oder gleich
viewparameter = "TOM"
USE rv_tabelle1 IN 0
Oder mach ALEN() auf das Array.
Tsch��, Olaf.
Stefan Wuebbe
Ich glaub nicht, dass _Tally mit Remote Servern funktioniert - hab
gerade in einem Test, bei dem Requery('testView') acht Zeilen im
Resultat hat, einen Wert von _tally=839
hth
-Stefan
"tom knauf" <hbg...@pdtgmbh.de> wrote in message
news:h7r1if$csp$03$1...@news.t-online.com...
tom knauf
vielen dank f�r die Hilfe.
Um den Select auf die View komme ich nicht herum, die View dient quasi f�r
viele Zwecke als Vorfilter (alles f�r den Kunden),
der Select dann mit unterschiedlichsten Bedingungen / Sortierungen f�r die
Endausgabe.
Verstehe ich das richtig : Die RV vorher mit Use �ffnen und dann darauf den
Select ?
Also funktioniert da implizite Use des Select nicht ?
(Alen vermeide ich, da ja bei _tally =0 das Array gar nicht erzeugt wird)
Nochmals Danke sch�n
tom
"Olaf Doschke" <b2xhZi5kb3NjaGt...@strconv.14.de> schrieb im
Newsbeitrag news:eaBx94VL...@TK2MSFTNGP03.phx.gbl...
tom knauf
ah, das ist eine klare Aussage.
Also muss ich vorab mit Use ein "mach eine tempdatei draus" erzwingen (wie
Olaf auch schrieb)
Das "Nach ein paar Sekunden stimmts schon" hat mich verwirrt.
Danke sch�n
Tom
"Stefan Wuebbe" <stefan...@gmx.de> schrieb im Newsbeitrag
news:%23OXgSHW...@TK2MSFTNGP02.phx.gbl...
Stefan Wuebbe
"tom knauf" <hbg...@pdtgmbh.de> wrote in message
news:h7r4ei$9ik$01$1...@news.t-online.com...
> Hallo Stefan,
>
> ah, das ist eine klare Aussage.
> Also muss ich vorab mit Use ein "mach eine tempdatei draus" erzwingen (wie
> Olaf auch schrieb)
W�rde RecCount() passen? Bei einem RemoteView- oder SPT-Cursor Alias
w�rde ich's probieren, wenn es um die Satzzahl direkt nach der Abfrage
geht, weil RecCount() schnell ist, weil's direkt aus dem "DBF"-Header liest.
> Das "Nach ein paar Sekunden stimmts schon" hat mich verwirrt.
Ja, merkw�rdig.
Gru�
-Stefan
Matthias Kahlert
> Oder mach ALEN() auf das Array.
Wenn kein Ergebnis rauskommt, enthï¿œlt das Array dennoch ein Feld. Ein
Array[0,0] gibt es schlieï¿œlich nicht...
ALEN() liefert also immer >= 1 zurï¿œck...
Matthias
tom knauf
ja, das Problem ist halt, das ich beim zweiten Select ein Problem habe :
mache in into array und es gibt keine Treffer fliegt der ALEN auf die Nase
(Olaf)
mache in into Cursor c_treffer und es gibt keine Treffer fliegt der Reccount
auf die Nase (Stefan)
Daher ja auch die Abfrage mit :
If _tally >0
sele c_treffer
do while ..
&& for n=1 to alen(.....
endif
Da man sich auf _tally nicht verlassen kann, bleibt mir wohl nix anderes als
noch ein paar Try/Catch oder andere Abfragen,
oder erstmal der Versuch mit dem Use nodata / Requery und die Hoffnung das
der _tally vom Select dann korrekt ist..
Seufzz
Nochmals vielen Dank an alle
Tom
"Stefan Wuebbe" <stefan...@gmx.de> schrieb im Newsbeitrag
news:utiDPSXL...@TK2MSFTNGP03.phx.gbl...
Matthias Kahlert
Oops... man sollte nicht schreiben, bevor man es nicht ausprobiert
hat... *hmpf*
Wenn der SELECT kein Ergebnis bringt, wird a) das Array gar nicht
erstellt bzw. b) ein bereits vorhandenes Array nicht verï¿œndert...
ALEN() bringt also nur bedingt etwas...
Matthias
tom knauf
sorry, as kann ich nicht nachvollziehen
Select * from adressen where pk_adressen = -1 into array an
? alen(an) ergibt Variable an nicht gefunden
Gr��e
tom
"Matthias Kahlert" <use...@max-pro.de> schrieb im Newsbeitrag
news:h7rd14$lbe$02$1...@news.t-online.com...
> Olaf Doschke schrieb:
>> Oder mach ALEN() auf das Array.
>
> Wenn kein Ergebnis rauskommt, enth�lt das Array dennoch ein Feld. Ein
> Array[0,0] gibt es schlie�lich nicht...
>
> ALEN() liefert also immer >= 1 zur�ck...
>
> Matthias
Stefan Wuebbe
"tom knauf" <hbg...@pdtgmbh.de> wrote in message
news:h7rd2e$ls3$02$1...@news.t-online.com...
> Moin, moin
>
> ja, das Problem ist halt, das ich beim zweiten Select ein Problem habe :
Mein Problem war, dass ich scheinbar die H�lfte der Beitr�ge nicht
gleich sehen konnte <s>
Jetzt hab ich alle, aber diesen Absatz verstehe ich noch nicht:
> mache in into array und es gibt keine Treffer fliegt der ALEN auf die Nase
> (Olaf)
> mache in into Cursor c_treffer und es gibt keine Treffer fliegt der
> Reccount auf die Nase (Stefan)
Wenn du die Select ... From remoteView Abfragen machst, (w�rde
ich auch wie Olaf empfehlen, die RemoteAnsicht zun�chst mit
"Use ... NoData" zu �ffnen, aber danach) m�sste zum einen die
weiteren "Unter"-Abfragen betreffend das _tally Ergebnis stimmen
(weil die weiteren, lokalen SQL Select ja von der lokalen
DBF('remoteView') Datei abfragen).
Und bei einem "Select ... From remoteView ... Into Cursor ergebnisCursor"
m�sste m.E. der ergebnisCursor in jedem Fall vorhanden sein, also
RecCount('ergebnisCursor ') eventuell 0, aber der Cursor w�rde immer
erstellt.
(Im Gegensatz zu ":.. Into Array ...", wo genau wie du sagst 0 S�tze ein
fehlendes Array ergeben.)
> Seufzz
:-)
Wenn ich mit dem gerade geschriebenen falsch liegen sollte, stimm'
ich in die Seufzerei mit ein.
hth
-Stefan
Bernhard Sander
> mache in into array und es gibt keine Treffer fliegt der ALEN auf die Nase
Dann teste doch bevor Du ALEN konsultierst mittels Type() oder VarType() ob das
Array angelegt wurde. Um sicher zu gehen kannst Du auch noch vor dem SELECT das
Array mit RELEASE ... löschen.
Gruß
Bernhard Sander
Olaf Doschke
recht, das ALEN() in dem Fall gar nicht funktioniert. Du brauchst dann einen
Vorabtest mittels TYPE(), ob "an" �berhaupt existiert.
Tsch��, Olaf.
Olaf Doschke
> den Select ?
> Also funktioniert da implizite Use des Select nicht ?
Das funktioniert schon, aber Du machst dann explizit ein Select
auf das ERgebnis eines Selects.
Wenn Dein remoteview schneller sein Endergbnis liefren soll und
Du sagst der View IST parameterisiert, dann nutzt Du das so
�berhaupt nicht.
Bei einem parameterisierten View nutzt man immer, indem man die
Viewparameterwerte setzt und ihn dann per USE �ffnet.
Du kannst danach dann auch nochmal selects machen, aber ein
SELECT * FROM remoteview WHERE bedingung INTO Cursor curResult
erstellt zwei cursoren, einen mit alias "remoteview", der die
komplette remotetabelle enth�lt und einen mit Alias curResult,
der das eingeschr�nkte Ergebnis enth�lt.
Ob Du statt INTO CURSOR nun INTO ARRAY nimmst, spielt auch keine
Rolle.
Das SELECT from view ist schon "falsch".
Ein view ist doch schon ein SQL-Select.
Du definierst CREATE SQL VIEW name AS SQL-Statement. Ein USE name
f�hrt dieses SQL-Statement aus.
Wenn Du views nutzt, dannn definierst Du die views mit den SQLs,
die Du brauchst und l��t die SQLs eben von den views ausf�hren,
statt SQL im Sourcecode zu haben. Das meine ich damit.
Tsch��, Olaf.
Stefan Wuebbe
Ich hab die Beschreibung so verstanden, dass es sich um eine
Art "Read-Only Offline Ressourcen" handelt, vielleicht z.B. um
Remote Daten, die nur selten ge�ndert werden und lokal an
vielen Stellen und jeweils anders gefiltert als Lookup-Daten
dienen.
In dem Fall macht das Vorgehen schon Sinn w�rde ich sagen -
eine gr��ere Menge Lookup Daten zw�rde .B. zu Beginn eines
Prozesses oder beim Programmstart geladen werden, und
dann nur noch nachgeladen werden, wenn eine kuze, schnelle
"Semaphoren" Abfrage per Stored Procedure o.�. ergibt, dass
sich inzwischen Daten ge�ndert haben.
hth
-Stefan
"Olaf Doschke" <olaf.d...@t-aufderlinie.de> wrote in message
news:466E5886-A508-4D24...@microsoft.com...
tom knauf
vielen Dank an alle f�r Eure Hilfe.
Ich use jetzt die RV mit Nodata und f�hre dann vor jedem Select
Programmschritt ein Requery durch.
Damit funktioniert es auch.
Gr��e
Tom
"tom knauf" <hbg...@pdtgmbh.de> schrieb im Newsbeitrag
news:h7r1if$csp$03$1...@news.t-online.com...
Olaf Doschke
> Art "Read-Only Offline Ressourcen" handelt, vielleicht z.B. um
> Remote Daten, die nur selten ge�ndert werden und lokal an
> vielen Stellen und jeweils anders gefiltert als Lookup-Daten
> dienen.
> In dem Fall macht das Vorgehen schon Sinn w�rde ich sagen -
> eine gr��ere Menge Lookup Daten zw�rde .B. zu Beginn eines
> Prozesses oder beim Programmstart geladen werden, und
> dann nur noch nachgeladen werden, wenn eine kuze, schnelle
> "Semaphoren" Abfrage per Stored Procedure o.�. ergibt, dass
> sich inzwischen Daten ge�ndert haben.
In dem Fall, okay.
Tom schrieb initial aber:
"Auf einer gro�en SQL-Tabelle (Tabelle1) liegt u.a. eine parametrisierte
Remoteview (rv_tabelle1)"
Au�erdem schrieb Tom sp�ter:
"View dient quasi f�r viele Zwecke als Vorfilter (alles f�r den Kunden),"
Also scheint mir die Viewparametrisierung Kundenweise zu sein, ein sehr
grober Vorfilter zwar, aber das kann u.U. doch immer noch sehr viele Daten
ziehen, das ist das ungeschickte daran. Egel, wie stark die erweiterte
Filterung ist, von Remote werden erst einmal alle Daten eines Kunden
gezogen.
An einem SELECT * FROM view WHERE ... insbesondere auf eine gro�e Tabelle
st�rt mich schon, da� man diese WHERE-Klausel nicht gleich mit in den View
oder einen weiteren View einbaut. Dann lieber zig oder hunderte von Views,
die unterschiedlichst gefilterte Ergebnisse liefern, als ein derartiges SQL
auf einen View. Zumindest aus Performancesicht und wenn Tom von "Nach 30s
ist _tally dann 0" spricht, dann sieht mir das danach aus, da� das nicht
optimal l�uft.
Angenommen der View ist allein definiert als
SELECT * FROM Tabelle Where kundenid=?lnKundenid
Und Tom macht darauf sein SQL: SELECT * FROM view WHERE nachname="TOM".
Dann macht er ein SELECT * FROM (SELECT * FROM Tabelle Where
kundenid=?lnKundenid) temp WHERE temp.nachname="TOM"
Und zwar wird der innere subselect, der View, remote ausgef�hrt, und auf das
Ergebnis dann der �u�ere SQL angewandt.
Definiert man stattdessen einen View
SELECT * FROM Tabelle Where kundenid=?lnKundenid AND nachname=?lcNachname
dann hat man von vornherein nur die Daten, die man gerade will.
Tsch��, Olaf.
tom knauf
du hast ja recht,
nur wir m�ssen die Remoteviews des Kunden aus "seiner" DBC als
Basisdatenquelle verwenden und d�rfen darauf unsere Abfragen machen
Weitere Parameter oder weitere Views sind nicht m�glich, garantiert
(Struktur,..) werden uns eben nur die Basisviews.
Daher die Konstruktion mit Select auf eine RV.
Gr��e
tom
"Olaf Doschke" <b2xhZi5kb3NjaGt...@strconv.14.de> schrieb im
Newsbeitrag news:uHsMMa8L...@TK2MSFTNGP05.phx.gbl...
Olaf Doschke
> Basisdatenquelle verwenden und d�rfen darauf unsere Abfragen machen
> Weitere Parameter oder weitere Views sind nicht m�glich, garantiert
> (Struktur,..) werden uns eben nur die Basisviews.
>
> Daher die Konstruktion mit Select auf eine RV.
Du k�nntest Dir per SQLGETPROP schon die Vieweinstellungen aus dem
DBC ziehen oder allgemeiner GENDBC daruf loslassen. Und dann kannst
Du einen weiteren eigenen lokalen DBC erzeugen, in dem dann weitere,
speziellere Views enthalten sind.
Zumindest f�r Views die langsam laufen w�re das eine lohnende
Sache.
Tsch��, Olaf.
Aragorn Rockstroh
eine alternative f�r die Alen()-Geschichte k�nnte sein, das Array vorher
mit der L�nge 1 zu initialisieren und zu leeren. Je nach dem was Du als
Ergebnis erwartest (zB mehr als 1 Feld), kannst Du vorher pr�fen, ob das
Array leer ist.
Bsp. (ungetestet)
Local antest[1]
m.antest = ""
Select * from daten1!rv_tabelle1 where nachname= 'TOM' into array
if (!Empty(m.antest) and Alen(m.antest) > 1)
...
endif
gru�,
ari
Aragorn Rockstroh
eine alternative f�r die Alen()-Geschichte k�nnte sein, das Array vorher
mit der L�nge 1 zu initialisieren und zu leeren. Je nach dem was Du als
Ergebnis erwartest (zB mehr als 1 Feld), kannst Du vorher pr�fen, ob das
Array leer ist.
Bsp. (ungetestet)
Local antest[1]
m.antest = ""
Select * from daten1!rv_tabelle1 where nachname= 'TOM' into array
Stefan Wuebbe
Nanu, Ari, was machst Du denn hier ... Und mit wem redest
Du �berhaupt, ich kann den Anfang des Threads in meinem
Thunderbird gar nicht sehen :-)
Gru�
-Stefan
tom knauf
danke f�r den Tip, aber wenn ich nur einen Treffer habe klappt es dann m.E.
nicht (ist ja schon mit 1 initialisiert)
Ich �ffne die RV jetzt vorher mit Use, darauf den "zweiten" Select, dann
gehts.
gr��e
tom
"Aragorn Rockstroh" <no...@nowhere.de> schrieb im Newsbeitrag
news:uRg5UNRb...@TK2MSFTNGP05.phx.gbl...
Aragorn Rockstroh
bekanntlich f�hren ja viele Wege nach Rom. Insofern freut es mich, da�
Du bereits einen gangbaren gefunden hast.
Dennoch eine Idee: Wenn Du nur einen R�ckgabewert erwartest, ist es
abh�ngig, wie Du das Array initialisierst. Mal angenommen Du fragst ein
Count(*) ab und erwartest Null Treffer. In dem Fall k�nntest Du zB so
initialisieren...
Local laTest[1]
m.laTest[1] = -1
...
If ( m.laTest[1] == 0)
...
Wie gesagt, alles nur Ideen um nach Rom zu kommen.
soweit,
ari
Aragorn Rockstroh
Hab's irgendwie geschafft, mal wieder die NGs bei mir zu aktivieren.
Aber man soll die NGs ja nicht zum Plauschen mi�brauchen. Deshalb hier
ein kleiner Tipp f�r Deinen Donnervogel. Du hast schon unter View->Sort
by->Threaded aktiviert?! Ansonsten triffst Du mich auch in Skype ;)
Gr��e an die Landungsbr�cken!
ari