Datenbank filtern

[Ewald]

Hallo und frohe Weihnachten,
irgendwie hat mir der Lebkuchen die Hirnwindungen verklebt.
Ich habe eine Datenbank TEST.DBF mit 2 Feldern NR und BEZ, beides Zeichen.
Im Feld NR befinden sich Daten wie "APOSDELE", "BPOSDELE" etc.
Die will ich rausfiltern. Ich bin mir (eigentlich) sicher, dass das immer so funktioniert hat.

Code: Alles auswählen

*Code 1
proc main
use test excl
set filter to "SDEL" $ nr
skip 0
browse()
close all
return

so geht es aber nicht. Es wird nichts gefunden.
arbeite ich mit gleichem Code mit einem alias()

Code: Alles auswählen

*Code 2
proc main
use test excl
test:=alias()
set filter to "SDEL" $ (test)->nr
skip 0
browse()
close all
return

werden die Daten gefunden. Ich habe die Datenbank schon mehrfach umbenannt. Hat damit
aber wohl nichts zu tun. Auch andere Suchbegriffe finde ich ohne alias nicht. Was ist denn da
wohl im Argen ?
Gruß
Ewald

[Ewald]

Um mich total zu verwirren funktionert dieses Beispiel auch.
Ist wie der Code 1 nur das Suchfeld NR ist geklammert.

Code: Alles auswählen

proc main
use test excl
set filter to "SDEL" $ (nr)
skip 0
browse()
close all
return

[Jan]

Hallo Ewald,

gibt es vielleicht irgendwo eine PRIVATE oder PUBLIC "nr"? Die anstelle des Feldes angesprochen wird?

Jan

[Ewald]

Hallo Jan,
der Code den ich hier abgebildet habe ist die kpl. Anwendung. Es gibt nirgendwo Variablen.

Grade habe ich Beispiel 1 mal mit Clipper 5e kompiliert. Klappt problemlos. Ohne Klammern und ohne alias.

Dann habe ich das Feld "nr" in "numm" umbenannt. Funktioniert mit xbase aber genau so wenig wie "nr".

Das sieht nach einer schlaflosen Nacht aus ...

[Ewald]

100 Test's später - da gibt es wohl einen entscheidenen Unterschied zwischen Clipper und Xbase.
Wenn der Feldname nicht geklammert ist, funktioniert der Filter in Xbase++ bei mir nicht. Ist mir in meinen
Anwendungen (zum grossen Teil aus Clippercode übernommen) bisher möglicherweise nur deswegen nicht unangenehm aufgefallen,
da ich die Filter fast immer mit upper(feldname) gesetzt habe. Dann funktioniert das in Xbase auch.
Hauptsache der Feldname ist geklammert.

Code: Alles auswählen

proc main
use test excl
set filter to "SDEL" $ upper(nr)
skip 0
browse()
close all
return

Kann aber auch sein, dass ich ab und an mal mit Filter gesucht und wegen der fehlenden Klammern nichts gefunden habe.
10 % Gehaltserhöhung für "BUCHALTUNG" $ ABTEILUNG ist dann zu XBASE-Zeiten persönliches Pech gewesen

[Jan]

Hallo Ewald,

interessante Erkenntnis. Schreib das doch mal Alaska, ob das Absicht ist oder ein Bug.

Ich selber habe das noch nie feststellen können, da ich Felder grundsätzlich mit Alias schreibe test->nr (eine Klammer ist nicht notwendig). Das hilft in vielen Bereichen sehr, insbesondere, wenn Du mehrere dbf offen hast. Oder wenn die Warnmeldungen des Compilers sensibel sind (was ich immer mache, hilft, den Code sauberer zu halten wegen Anmeckerns nicht benutzter und nicht deklarierter Variablen).

Jan

[Ewald]

Hallo Jan,
nur den Namen der offenen DBF voranstellen geht bei mir auch nicht.
Wenn ich in Code 1 "test->nr" verwende wird auch nichts gefunden.
Siehe Code 2.
Ich muß den alias() extra auslesen und dann (test)->nr angeben. Wäre ja dann wohl test_1.dbf
denke ich.
Oder alternativ (nr) oder auch upper(nr) - (wenn alles wie bei mir gross geschrieben wird)

Dann geht es.
Wäre toll, wenn du dir mal bei Gelegeheit eine DBF mit 2 Feldern generieren würdest
und das nachvollziehen könntest. Inhalt ist egal. Mittlerweile habe ich festgestellt, dass es in
keiner meiner Datenbanken ohne alias oder Klammern funktioniert.
Die Sache hat in der Tat eine gewisse Brisanz, da es ja zu keiner Fehlermeldung kommt,
sondern nur tatsächlich vorhandene Sätze nicht gefunden werden.
Ich selbst habe mich da blind drauf verlassen, da es unter Clipper jahrelang gut gegangen ist.
Wichtige Daten finde ich (hoffentlich) allerdings immer über Index-Suche.
Gemerkt habe ich das jetzt, da ich mir mal einen DBF-Editor für meine Anwendungen geschrieben
habe und jetzt Daten nicht aufgetaucht sind, von denen ich 100%ig sicher war, dass sie in der
Datenbank stehen müssen.
Der gleiche DBF-Editor mit Clipper erzeugt zeigt die Daten dann an.

[Ewald]

Da habe ich Blödsinn geschrieben. Stimmt so nicht, der alias ist nicht test_1 sondern auch test.
Aber ich habe das nochmal ausprobiert, obwohl der alias in beiden Fällen gleich wäre:

1. Code 3 funktioniert

Code: Alles auswählen

*Code 3
proc main
use test excl
test:=alias()
set filter to "SDEL" $ (test)->nr    // es ginge auch (nr) oder upper(nr)
skip 0
browse()
close all
return

2. Code 4 funktioniert nicht

Code: Alles auswählen

*Code 4
proc main
use test excl
set filter to "SDEL" $ test->nr
skip 0
browse()
close all
return

Da hakt es bei mir dann etwas am Verständis.

[brandelh]

Hallo,

unter CLIPPER war es so, dass der Dateiname auch gleich dem automatischen Aliasnamen war.
Unter Xbase++ KANN das gar nicht sein, da man ja einmal mit langen Namen rechnen muss und zum zweiten
bei mehrfachem Öffnen eines Fensters diese andere Aliase brauchen.

Ich dachte zwar auch (aus dem Gedächtnis), dass use test zu Alias() -> test würde, aber es kann
auch sein, dass grundsätzlich Dateiname (kurz) + Selectbereich genutzt wird.
Entweder du schreibst direkt den gewünschten Alias (was bei kurzen Auswertungen kein Problem ist !)
oder du fragst den Selectbereich ab und speicherst diesen wie oben gezeigt.

Du solltest auch mal die Compilerschalter überprüfen, da gibt es einen der festlegt ob eine
unbekannte Variable zuerst bei den Feldern (ich meine Standard) oder als private gelesen werden soll.
Im letzten Fall SOLLTE dann zwar ein "Variable nicht initialisiert" kommen, aber wie vor kurzem festgestellt,
ist der FILTER deutlich flexibler als es für unsere "Vertipper" sinnvoll wäre.

[Ewald]

Hi Hubert,
use test ergibt alias test und nicht - wie ich erst angenommen habe test_1. Da täuscht dich deine Erinnerung nicht.
Aber warum der Code 4 dann nicht funktioniert erschließt sich mir nicht.
Ich habe da noch einen absurden Verdacht den ich morgen aus dem Weg räume. Vllt ist der alias ja nicht "test" sondern "test " und ich suche nach "test ->nr". Aber dann würde ich mit einem Laufzeitfehler rechnen

[Ewald]

Ich habe es nicht knacken können warum die Klammern gebraucht werden. Hat aber irgendwas mit der Substring Suche zu tun.
Wenn ich den Filter so wie unten setze, brauche ich weder einen alias noch irgendwelche Klammern. "nr" wird als Feldvariable erkannt und der Begriff wird gefunden.
Man muss es halt nur wissen ...

Code: Alles auswählen

*Code 5
proc main
use test excl
set filter to nr = "#APOSDELE" 
skip 0
browse()
close all
return

[Juergen]

Hallo Ewald,

ich würde upper(alltrim(test->nr)) versuchen.

Gruß Jürgen.

[Tom]

Hallo, Ewald.

Kannst Du Deine Testdatenbank mal posten (am besten als ZIP an eine Nachricht anhängen)?

[Ewald]

Hallo Tom,
ein DBF-Auszug und Quellcode ist per PN unterwegs. Das Problem, das nichts gefunden wird, habe ich allerdings mit allen getesteten Datenbanken und mit allen Filtern, mit denen ich auf Substringsuche gehe und das Feld nicht in Klammern setze. Ich meine, jetzt wo ich es gemerkt habe, habe ich das Problem nicht mehr, aber ich denke, da bin ich nicht der Erste der stolpert.

Gruß
Ewald

[AUGE_OHR]

Code: Alles auswählen

*Code 1
proc main
use test excl
set filter to "SDEL" $ nr
skip 0
browse()
close all
return

du kommst auf die "Lösung" wenn du es mal mit /w compilierst

test.prg(4:0): warning XBT0102: Ambiguous variable reference nr

... am Anfang war dBase][ als Interpreter d.h. man hat "direkt" in der DBF gearbeitet (FIELD)
auch "konnte" man Code in Form von Proceduren schreiben die mit SET PROCEDURE TO aktiviert wurden.

... viele Jahre später gab es dann einen Compiler, Cl*pper S87 genannt ...

naja und Xbase++ hat das ganze nun zwar "übernommen", aber da Xbase++ "strenger" als Cl*pper ist meckert er nr als "Variabel" an ...
Xbase++ "weiss" nicht das es sich um ein FIELD handelt !

a.) mit Alias-> "weiss" Xbase++ das es sich um ein FIELD handelt
b.) (nr) ist ja ein "Makro" ... es "müsste" auch mit &nr funktionieren

Also wenn möglich immer den Alias-> angeben und bei "Makro" mit (cAlias)-> oder &cAlias-> versuchen.

wenn du das Modul nun für mehrere Instanzen mit verschiedenen Alias benutzen würde ich FIELD verwenden was auch Cl*pper "eindeutig" versteht.

[Rolf Ramacher]

Hi zusammen,

ich setze Filter mit Dbsetfilter - d.h. hier wird die Datenbank direkt mit angesprochen, kann es vielleicht daran liegen.

Code: Alles auswählen

			Spstamm->(DbSetFilter( {|| ss<>"8"} ))

[Ewald]

Hi Jimmi,

a.) mit Alias-> "weiss" Xbase++ das es sich um ein FIELD handelt

habe ich mit Code 4 weiter oben geschrieben.
Selbst mit test->nr geht es nicht. Xbase erkennt bei der Substringsuche nicht !!!, dass es sich um eine Feldvariable handelt.
Der compiler meckert den gleichen Fehler an und die gesuchten Daten werden nicht gefunden.

Hi Rolf,
nimm es als Warnung

Code: Alles auswählen

use test excl
test->(DbSetFilter( {|| "DELE" $ nr} ))

funktioniert so nicht. Auch in diesem Beispiel wird "nr" auch nicht !!! als Feldvariable erkannt und die Daten werden schlicht überlesen.

Auch mit der Funktion muss es heissen

Code: Alles auswählen

use test excl
test->(DbSetFilter( {|| "DELE" $ (nr)} ))

Das ist in jeder beliebigen Datenbank mit einem 4zeiler nachzuvollziehen.

Ich zitiere mich noch mal selbst.

Ich meine, jetzt wo ich es gemerkt habe, habe ich das Problem nicht mehr, aber ich denke, da bin ich nicht der Erste der stolpert.

Gruß
Ewald

[AUGE_OHR]

hi,

da es bei mir immer am Anfang des MAIN Modul steht habe ich "vergessen" das man, seit v1.8 für Cl*pper Code, folgende Einstellungen nehmen sollte :

Code: Alles auswählen

SET OPTIMIZE OFF

der den "Mist" macht. auch die RUSHMORE und SMARTFILTERsind nichts für Cl*pper Code.

[Ewald]

Hi Jimmy,
stimmt, wenn ich die "Optimierung abschalte" finde ich auch meine Daten. Das lasse ich dann mal unkommentiert
Und was Rushmore anbelangt, da fahre ich doch lieber zum gleichnamigen MOUNT.
Danke.

Das funktioniert.

Code: Alles auswählen

proc main
set optimize off
use test excl
set filter to "DELE" $ nr
skip 0
browse()
close all
return

Gruß
Ewald