Das nächste Entwicklertreffen findet Anfang Mai in Münster statt - weitere Infos bzw. zur Anmeldung!

INDEXKEY() "zerlegen"

Alles zum SQL-Dialekt

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

INDEXKEY() "zerlegen"

Beitrag von AUGE_OHR » Sa, 28. Jul 2012 3:06

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.
gruss by OHR
Jimmy

UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2543
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Kontaktdaten:

Re: INDEXKEY() "zerlegen"

Beitrag von UliTs » So, 29. Jul 2012 16:11

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
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: INDEXKEY() "zerlegen"

Beitrag von AUGE_OHR » Mo, 30. Jul 2012 4:51

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 ?
gruss by OHR
Jimmy

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 14597
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: INDEXKEY() "zerlegen"

Beitrag von Martin Altmann » Mo, 30. Jul 2012 4:55

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
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: INDEXKEY() "zerlegen"

Beitrag von AUGE_OHR » Mo, 30. Jul 2012 5:10

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 ???
gruss by OHR
Jimmy

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 14597
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: INDEXKEY() "zerlegen"

Beitrag von Martin Altmann » Mo, 30. Jul 2012 5:13

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
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: INDEXKEY() "zerlegen"

Beitrag von AUGE_OHR » Di, 31. Jul 2012 21:46

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
gruss by OHR
Jimmy

bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: INDEXKEY() "zerlegen"

Beitrag von bgl » Mi, 01. Aug 2012 14:39

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?

georg
Foren-Administrator
Foren-Administrator
Beiträge: 2255
Registriert: Fr, 08. Feb 2008 21:29

Re: INDEXKEY() "zerlegen"

Beitrag von georg » Mi, 01. Aug 2012 14:46

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
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.

bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: INDEXKEY() "zerlegen"

Beitrag von bgl » Mi, 01. Aug 2012 14:49

PostgreSQL hat keine Probleme mit TEXT - im Gegensatz zu MySQL ist TEXT schneller als VARCHAR (lange Geschichte).

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: INDEXKEY() "zerlegen"

Beitrag von AUGE_OHR » Mi, 01. Aug 2012 23:20

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" ...
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14632
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: INDEXKEY() "zerlegen"

Beitrag von brandelh » Mi, 01. Aug 2012 23:53

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
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11551
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: INDEXKEY() "zerlegen"

Beitrag von AUGE_OHR » Do, 02. Aug 2012 0:33

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 ...
gruss by OHR
Jimmy

bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: INDEXKEY() "zerlegen"

Beitrag von bgl » Do, 02. Aug 2012 0:42

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.

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14632
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: INDEXKEY() "zerlegen"

Beitrag von brandelh » Do, 02. Aug 2012 10:48

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
Gruß
Hubert

georg
Foren-Administrator
Foren-Administrator
Beiträge: 2255
Registriert: Fr, 08. Feb 2008 21:29

Re: INDEXKEY() "zerlegen"

Beitrag von georg » Do, 02. Aug 2012 11:03

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
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14632
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: INDEXKEY() "zerlegen"

Beitrag von brandelh » Do, 02. Aug 2012 11:08

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
Gruß
Hubert

Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 18200
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel

Re: INDEXKEY() "zerlegen"

Beitrag von Manfred » Do, 02. Aug 2012 11:09

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.
Gruß Manfred
Mitglied der XUG Leverkusen
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite

Antworten