Inoffizielles deutsches Xbase-Forum

Das deutschsprachige Forum für Entwickler in der Xbase-Welt, ein Angebot des Deutschsprachige Xbase-Entwickler e. V.
https://xbaseforum.de/

INDEXKEY() "zerlegen"

https://xbaseforum.de/viewtopic.php?t=6417

Seite 1 von 1

INDEXKEY() "zerlegen"

Verfasst: Sa, 28. Jul 2012 3:06
von AUGE_OHR
hi,

ich möchte den INDEXKEY() zur Laufzeit "zerlegen" um ihn für SQL Syntax zu verwenden.

Indexe als "primary key" haben bei mir meistens nur 1 Feld, also kein Problem.
das "+" Zeichen als "Trenner" ist auch klar.

Code: Alles auswählen

   _key := "KDNR"
   _key := "DECRYPT(KDNAME)+DECRYPT(PLZ)"
   _key := "DECRYPT(PLZ)+SUBSTR(DECRYPT(KDNAME),1,3)"
   _key := "SUBSTR(DECRYPT(ORT),1,7)+SUBSTR(DECRYPT(KDNAME),1,3)"
   _key := "DECRYPT(STRASSE)"
   _key := "DECRYPT(TELEFON)+DECRYPT(VORTELE)"
   _key := "DECRYPT(KONTONR)"
   _key := "ARTNR"
   _key := "ARTIKEL+ARTNR"
   _key := "CODE"
   _key := "STRZERO(WARENGRUPE,3)"
   _key := "URECHNR"
   _key := "UKDNR+URECHNR"
   _key := "UKDNR+OK"
   _key := "FJAHR+'-'+STR(FNUMMER,5)"
   _key := "DFLAG+FJAHR+'-'+STR(FNUMMER,5)"
   _key := "FKDNR+FJAHR+'-'+STR(FNUMMER,5)"
   _key := "FJAHR+'-'+STR(FNUMMER,5)"
   _key := "SKDNR+SARTNR"
   _key := "FJAHR+'-'+STR(FNUMMER,5)"
   _key := "FARTNR+FFJAHR+FFMONAT+FFTAG"
   _key := "AQNR+LIEFNR"
   _key := "FFJAHR+LIEFNR"
   _key := "LFLAG+FFJAHR+LIEFNR"
   _key := "FFJAHR+FFMONAT+FFTAG+FARTNR"
   _key := "FARTNR+FFJAHR+FFMONAT+FFTAG+LIEFNR"
   _key := "FKDNR+FFJAHR+FFMONAT+FFTAG"
   _key := "FKDNR+FARTNR"
   _key := "FKDNR+IF(EMPTY(FNUMMER),'J','N')+FFJAHR+FFMONAT+FFTAG"
   _key := "FFJAHR+LIEFNR"
   _key := "FFJAHR+LIEFNR"                         // UNIQUE
   _key := "LADEJAHR+STRZERO(LADENR,5)"
   _key := "TOURKW+LKW+STRZERO(WAHLNR,5,2)"
   _key := "TOURKW+LKW"
   _key := "FFJAHR+LIEFNR"
   _key := "ZBANK+DTOC(ZDATUM)"
   _key := "ZKDNR+ZRGNR"
   _key := "ZUSER+DTOC(ZUSERDATE)"
   _key := "ZRGNR"
   _key := "ABZUNR+ABZUOK+DTOS(ABZUDATE)"
   _key := "ABZUNR+DTOS(ABZUDATE)"
   _key := "ABZUREF+ABZUNR"
   _key := "DTOS(ABZUDATE)+ABZUMODUS+ABZUNR"
   _key := "ABZUOK+ABZUPLATZ"
   _key := "ABZUOK+ABZUNR"
   _key := "QARTNR+QNUMMER"
   _key := "QNUMMER"
   _key := "DTOS(QHALTBAR)"
   _key := "KREDNR"
   _key := "UPPER(KREDNAME1)"
   _key := "ARTNR"
   _key := "ARTNEU"
   _key := "ARTNR"
   _key := "UPPER(VONUSER)+STR(GELESEN,1)+DTOS(DATUM)"
   _key := "UPPER(ANUSER)+STR(GELESEN,1)+DTOS(DATUM)"
   _key := "STRZERO(WARENGRUPE,3)"
unter Xbase++ ist der INDEXKEY() gewöhnlich Type "C" und ich muss andere Datentypen "konvertieren".
Das muss ich offensichtlich für SQL nicht da ich Fields "gemischte" benutzten kann, oder ?

Code: Alles auswählen

SELECT * FROM ABC ORDER BY cName, nNummer, dTag
d.h. DTOS(), STR() könnten raus... oder sollte ich das STR() "ersetzen" durch die entsprechende SQL Function ?
wie "konvertiere" ich String -> Num , Num -> String ? mir fehlt STR() und VAL()

was gibt es für STRZERO() als "Ersatz" ? ... ich bin mir nicht sicher ob ich ohne "führenden 0" auskomme

und dann gibt es noch einen INDEXKEY() mit UNIQUE.
ich finde es im Zusammenhang mit Table und Index

Code: Alles auswählen

CREATE UNIQUE INDEX
aber nicht mit einem "SELECT" für so was

Code: Alles auswählen

SELECT * FROM ABC ORDER BY UNIQUE FFJAHR,LIEFNR
das UNIQUE soll hierbei nur die 1st Position von jedem Lieferschein in den Index aufnehmen.

Re: INDEXKEY() "zerlegen"

Verfasst: So, 29. Jul 2012 16:11
von UliTs
AUGE_OHR hat geschrieben: wie "konvertiere" ich String -> Num , Num -> String ? mir fehlt STR() und VAL()

was gibt es für STRZERO() als "Ersatz" ? ... ich bin mir nicht sicher ob ich ohne "führenden 0" auskomme

und dann gibt es noch einen INDEXKEY() mit UNIQUE.
ich finde es im Zusammenhang mit Table und Index

Code: Alles auswählen

CREATE UNIQUE INDEX
aber nicht mit einem "SELECT" für so was

Code: Alles auswählen

SELECT * FROM ABC ORDER BY UNIQUE FFJAHR,LIEFNR
das UNIQUE soll hierbei nur die 1st Position von jedem Lieferschein in den Index aufnehmen.
Hallo Jimmy,

im ADS können alle Scalarfunktionen in SQL Statements verwendet werden.
Man keinen Index über eine Teilmenge erstellen. Ist in SQL auch sinnlos.
Du kannst z.B. eine View erstellen, die von jedem Lieferschein nur die erste Position enthält und hast das gleiche Ergebnis.[/code]
Uli

Re: INDEXKEY() "zerlegen"

Verfasst: Mo, 30. Jul 2012 4:51
von AUGE_OHR
UliTs hat geschrieben:Du kannst z.B. eine View erstellen, die von jedem Lieferschein nur die erste Position enthält und hast das gleiche Ergebnis.
für UNIQUE gibt es ja einen Befehl, also sollte das kein Problem.

ich hätte dazu sagen sollen das ich den "Index" ja hinterher auch "verwenden" will.
ein "ORDER BY "+cFields soll zusammen mit "WHERE "+cFields zusammen arbeiten und könnte zu solchen Konstruktionen führen

Code: Alles auswählen

ORDER BY cFeld,nNum WHERE VAL(SUBSTR(cFeld,1,1)) > 1
... und VAL() kennt PostgreSQL nicht ?

Re: INDEXKEY() "zerlegen"

Verfasst: Mo, 30. Jul 2012 4:55
von Martin Altmann
Moin Jimmy,
AUGE_OHR hat geschrieben:... und VAL() kennt PostgreSQL nicht ?
und nun weißt Du auch, was der Sinn der Alaska-eigenen Indexfelder ist, die mittels Trigger auf dem aktuellen Stand gehalten werden.

Viele Grüße,
Martin

Re: INDEXKEY() "zerlegen"

Verfasst: Mo, 30. Jul 2012 5:10
von AUGE_OHR
moin,
Martin Altmann hat geschrieben:und nun weißt Du auch, was der Sinn der Alaska-eigenen Indexfelder ist, die mittels Trigger auf dem aktuellen Stand gehalten werden.
versuch mal DbfUpSize.EXE mit solchen INDEXKEY() zu bestücken ... :badgrin:

im übrigen : was soll der Trigger den "mehr" können als pgAdmin.EXE der VAL() nicht kennt ???

Re: INDEXKEY() "zerlegen"

Verfasst: Mo, 30. Jul 2012 5:13
von Martin Altmann
Nun,
mittels Trigger kannst Du eine Aktion auslösen - in dem Fall halt ein Feld mit einem "komplexen" Indexausdruck in Stringform füllen.

Viele Grüße,
Martin

Re: INDEXKEY() "zerlegen"

Verfasst: Di, 31. Jul 2012 21:46
von AUGE_OHR
hi,
Martin Altmann hat geschrieben:mittels Trigger kannst Du eine Aktion auslösen - in dem Fall halt ein Feld mit einem "komplexen" Indexausdruck in Stringform füllen.
was ein Trigger machen soll ist mir schon klar nur dafür muss er :
a.) angelegt werden
b.) entsprechende Function haben

ad a.) sagte ich ja das es viele INDEXKEY() Ausdrücke gibt die DbfUpsize.EXE nicht "frisst".
die Frage ist dann "warum" ...

ad. b.) ich suche ja solche Function wie VAL() ... ich hab da nun was gefunden
to_number(text,
text)
numeric Zeichenkette in numeric umwandeln to_number('12,454.8-',
'99G999D9S')
hm ... da sind ja "G", "D" und "S" vorhanden ... sind das "Platzhalter" ?

das Gegenstück würde dann

Code: Alles auswählen

to_char(int, text) text integer in Zeichenkette umwandeln to_char(125, '999')
sein wobei man "aufpassen" muss da es auch für Datum gilt

Re: INDEXKEY() "zerlegen"

Verfasst: Mi, 01. Aug 2012 14:39
von bgl

Code: Alles auswählen

zensiert=# SELECT 1234::TEXT || '--' || 'asdf'::TEXT || '-->nochmehrgeruempel'::TEXT || NOW()::TEXT AS tehFieldishThing;
                      tehfieldishthing
------------------------------------------------------------
 1234--asdf-->nochmehrgeruempel2012-08-01 13:52:18.90057+00
(1 Zeile)
Hilft dir das weiter?

Re: INDEXKEY() "zerlegen"

Verfasst: Mi, 01. Aug 2012 14:46
von georg
Hallo, Jimmy -


habe ich Deine Frage so verstanden: "Wie muss ich meinen Index-Begriff unter SQL angeben? Benötige ich Konvertierungsfunktionen wie in Xbase++?"

Die Antwort lautet "nein". SQL "versteht" Deine Anforderung

Code: Alles auswählen

ORDER BY Auftragsnummer, Eingangsdatum, PLZ, Ausgeliefert
wobei wir unterstellen können, dass

Auftragsnummer = INT
Eingangsdatum = DATE
PLZ = CHAR
Ausgeliefert = BOOLEAN

definiert sind.

Entsprechend musst Du auch beim Index-Erstellen nicht alle Felder nach CHAR "zwingen":

Code: Alles auswählen

CREATE INDEX Hugo1 ON Hugo (Auftragsnummer, Eingangsdatum, PLZ, Ausgeliefert)
Einzige Einschränkung: TEXT und BLOB Felder sind im Index nicht gut gelitten, da muss man dann mit Substring() oder Left() arbeiten, wenn man sie verwenden will.

Oder war Deine Frage eine andere?


Gruss,

Georg

Re: INDEXKEY() "zerlegen"

Verfasst: Mi, 01. Aug 2012 14:49
von bgl
PostgreSQL hat keine Probleme mit TEXT - im Gegensatz zu MySQL ist TEXT schneller als VARCHAR (lange Geschichte).

Re: INDEXKEY() "zerlegen"

Verfasst: Mi, 01. Aug 2012 23:20
von AUGE_OHR
georg hat geschrieben:habe ich Deine Frage so verstanden: "Wie muss ich meinen Index-Begriff unter SQL angeben? Benötige ich Konvertierungsfunktionen wie in Xbase++?"

Die Antwort lautet "nein". SQL "versteht" Deine Anforderung
schönes Beispiel wie einfach es mit SQL sein kann, DANKE =D>

angenommen du hast eine DBF mit einem Feld "C",6 und dort ist eine (kurzes) Datum als DDMMYY gespeichert und du "importierst" es "so" nach PostgreSQL.
ja es wird "funktionieren" aber das Ergebniss nach DDMMYY "sortiert" ergibt ja "Unsinn".

ich möchte nun auch die Xbase++ Indexe nach PostgreSQL "importieren" , allerdings nur den INDEXKEY(), in ein Data-Dic.

allerdings muss ich den INDEXKEY() immer noch zerlegen um die Xbase++ FUNCTION zu entfernen und ggf. dafür eine PostgreSQL "function" schreiben.

klar ist es nicht sinnvoll ein solches Field "so" zu verwenden, aber so lange man den "Rattenschwanz" nicht absehen kann wäre es gefährlich das Format zu ändern.

deshalb frage ich nach möglichst vielen INDEXKEY() Ausdrücken die beim "zerlegen" für Probleme sorgen könnten.
... alles was ich in die Finger bekomme habe wurde ja schon vom mir "zerlegt" ... ich brauche "mehr" ...

Re: INDEXKEY() "zerlegen"

Verfasst: Mi, 01. Aug 2012 23:53
von brandelh
AUGE_OHR hat geschrieben:angenommen du hast eine DBF mit einem Feld "C",6 und dort ist eine (kurzes) Datum als DDMMYY gespeichert und du "importierst" es "so" nach PostgreSQL. ja es wird "funktionieren" aber das Ergebniss nach DDMMYY "sortiert" ergibt ja "Unsinn".
und welcher D... sollte sowas nach dem Jahre 2000 noch vor haben angry9: :D

Re: INDEXKEY() "zerlegen"

Verfasst: Do, 02. Aug 2012 0:33
von AUGE_OHR
brandelh hat geschrieben:und welcher D... sollte sowas nach dem Jahre 2000 noch vor haben angry9: :D
viele ... besonders wenn man Daten von > 25 Jahren hat ! aber ich sagte ja ... "Rattenschwanz" ... besonders wenn solche Felder im INDEYKEY() auftauchen ...

pgDBE biete wiedermal die Chance solche Konzepte zu überarbeiten.
wenn man seine DBF Daten mal nach PostgreSQL importiert wird man wieder auf "solche" Problem aufmerksam gemacht und die Arbeit fängt an ...

Re: INDEXKEY() "zerlegen"

Verfasst: Do, 02. Aug 2012 0:42
von bgl
AUGE_OHR hat geschrieben:angenommen du hast eine DBF mit einem Feld "C",6 und dort ist eine (kurzes) Datum als DDMMYY gespeichert und du "importierst" es "so" nach PostgreSQL.
ja es wird "funktionieren" aber das Ergebniss nach DDMMYY "sortiert" ergibt ja "Unsinn".
Eigentlich sollte ich das lieber nicht an dieser Stelle erwähnen, aber ORDER BY TO_DATE(ddmmyy_feld, 'DDMMYY') duerfte eine sinnvolle Sortierung ergeben. Allerdings vermutlich keine besonders Schnelle.

Re: INDEXKEY() "zerlegen"

Verfasst: Do, 02. Aug 2012 10:48
von brandelh
AUGE_OHR hat geschrieben:viele ... besonders wenn man Daten von > 25 Jahren hat ! aber ich sagte ja ... "Rattenschwanz" ... besonders wenn solche Felder im INDEYKEY() auftauchen ...
pgDBE biete wiedermal die Chance solche Konzepte zu überarbeiten.
wenn man seine DBF Daten mal nach PostgreSQL importiert wird man wieder auf "solche" Problem aufmerksam gemacht und die Arbeit fängt an ...
Spätestens im Jahre 1999 hätten diese Daten schon auf 4 stellige Jahreswerte umgestellt werden müssen ;-)
NOCH kann man einigermaßen aus den Werten und Umständen das Jahrhundert "19" oder "20" automatisch zuordnen, aber wenn noch einige Jahre ins Land gehen [-X

Re: INDEXKEY() "zerlegen"

Verfasst: Do, 02. Aug 2012 11:03
von georg
Hallo, Hubert -


TTMMJ ging aber auch gut. Wir haben das damals im Rahmen der Y2K-Umstellung auf Datumsfelder umgestellt (die gab es in den 80er Jahren, als die Programme geschrieben wurden, noch nicht :D), aber diese Programme waren Jahr-2000 fähig, weil dieses "Problem" halt alle 10 Jahre auftrat.

Aber es wird Generationen von Programmierern geben, die uns verfluchen, weil wir den Y10K Bug (Wechsel von 9.999 auf 10.000) so einfach hätten verhindern können, aber da wir damals ja meinten, mit einem vierstelligen Jahr wäre alles geregelt ...


Gruss,

Georg

Re: INDEXKEY() "zerlegen"

Verfasst: Do, 02. Aug 2012 11:08
von brandelh
georg hat geschrieben:Aber es wird Generationen von Programmierern geben, die uns verfluchen, weil wir den Y10K Bug (Wechsel von 9.999 auf 10.000) so einfach hätten verhindern können, aber da wir damals ja meinten, mit einem vierstelligen Jahr wäre alles geregelt ...
da muss ich vehement wiedersprechen, spätestens im Jahre 6666 kommt die Hyperdynamische Warp Raum-Zeit-Vektor Umstellung.
Da ich dann schon in Rente bin, muss das mein Nachfolger erledigen ... :D

Re: INDEXKEY() "zerlegen"

Verfasst: Do, 02. Aug 2012 11:09
von Manfred
Georg,

dann treffen wir uns wieder hier im Forum und werden das nochmal durchdiskutieren, ob das wirklich leichtsinnig war, dass wir uns heute nicht darum gekümmert haben.
Alle Zeiten sind UTC+02:00
Seite 1 von 1

Powered by phpBB® Forum Software © phpBB Limited

Deutsche Übersetzung durch phpBB.de