PostgreSQL native

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Ich interessiere mich für die native PostgreSQL Schnittstelle

JA
6
75%
NEIN
2
25%
 
Insgesamt abgegebene Stimmen: 8

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

zurück zum Thema Index

ich hatte schon im anderen Thread über den PostgreSQL Index gesprochen und das dass xBase "Denken" da mal wieder eine Rolle spielt. :roll:

---

ohne Index würde man unter xBase LOCATE verwenden was einem WHERE in SQL entspricht.
wenn wir in xBase einen Index erzeugen müssen wir SEEK / FIND nutzen und den Suchbegriff als Argument.
klar das wir in xBase "den" Index aktiveren müssen mit OrdSetFocus()

ein SQL Index arbeitet völlig anders was die Verwendung angeht denn das bestimmt der SQL Server :!:
bei ein SQL Qwery "sucht" der SQL Server nach einem "passenden" Index zu ORDER während die Syntax von WHERE nicht geändert werden muss.

zum "suchen" und der Bewertung von "passend" gibt ANALYZE die "Kosten" an. wo die wenigsten "Kosten" sind da "passt" es am besten :D

---

unter xBase kann ein IndexKey() über mehrer Felder gehen. ein SQL Index verwendet üblicherweise nur ein FIELD.

Code: Alles auswählen

   CREATE INDEX cIndex_Name ON cTable_Name (cField_Name)
ein Index hat als "Neben Effect" eine (BTREE) Sortierung und das ist gemeint wenn man mehrere Felder im IndexKey() hat.

das war nun der Punkt zu meiner Theorie warum PgDBE die internen Index FIELD hat die man IMHO nicht benötigt [-X

unter SQL gibt es ORDER BY was dafür zuständig ist :!:

wenn das erste Argument von ORDER BY das selbe FIELD wie "in" einem Index ist wird der Index vom Server aktiviert.

---

üblicherweise ist ein xBase IndexKey() ein String d.h. man muss alles nach Type "C" umwandeln
unter SQL können die Argumente für ORDER BY jeden Type haben !

Code: Alles auswählen

SELECT * FROM artikel ORDER BY artnr,artikel,apreis LIMIT 100
wenn man einen IndexKey() Ausdruck für SQL verwenden will muss man alle xBase Function entfernen :!:
die Feldname bekommt man ja mit DbStruc() die ich mit dem IndexKey() Ausdruck vergleichen kann.

es reicht also wenn ich von den xBase Index Dateinen den IndexKey() hole/speichere mit DBF Namen zu den die gehören.

um einen xBase Index zu simulieren brauche ich nur in der Qwery mit ORDER BY den bearbeiteten IndexKey() als Argument angeben.

die Information in den internen Index FIELD werden deshalb NICHT gebraucht [-X
ich brauche PostgreSQL Index und ein FIELD reicht aus :!:
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: PostgreSQL native

Beitrag von ramses »

Hallo Jimmy
du hast mit PQescapeStringConn() grundsätzlich Recht ... wenn man solche Zeichen hat.
ich verwende auch NICHT UTF-8 sondern Win 1252 und arbeitet mit OEM also sollte keine Zeichen > 128 vorkommen wo ich das beachten müsste.
Diese Aussage möchte ich nicht wirklich öffentlich kommentieren.

Damit begehst du einen Denkfehler "höchster Güte". Jeder String der aus einem Eingabefeld, dem Web oder einer sonstigen fremden Quelle kommt MUSS IMMER als GEFAHR eingestuft und getestet werden. Ob solche problematischen Zeichenfolgen vom Benutzer aus Unachtsamkeit, Boshaftigkeit oder krimineller Absicht in ein Feld eingesetzt werden spielt gar keine Rolle. Das überprüfen ist in jedem Fall ein muss. Lässt du diese Prüfung Weg handelst du als Sachkundiger vermutlich bereits grobfahrlässig.
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

ok das hab ich jetzt verwechselt.

ich verstehe jetzt aber nicht deinen Zusammenhang mit dem String beim übertragen einer DBF in einer Table :?:
klar ist es ein String der grundsätzlich gefährlich sein könnte aber beim import bekannter DBF Daten prüfe ich das nicht [-X

die Anbindung an das Internet hab ich nicht im Blick, also bin ich Dankbar für deinen Hinweis.

klar könnte auch ein User bei einer Eingabe "schädlichen" Code eingeben aber das wäre die Prüfung des String bevor man die Qwery abschickt.
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: PostgreSQL native

Beitrag von Jan »

Kann man in PostgreSQL auch zusammengesetzte Indizes nutzen, und mit eigenen Funktionen darin?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

Jan hat geschrieben: Sa, 06. Jul 2019 9:32 Kann man in PostgreSQL auch zusammengesetzte Indizes nutzen, und mit eigenen Funktionen darin?
ab v9.1 kann man 2 FIELD im Index haben ... wenn ORDER BY nicht reichen sollte.

in einer Qwery kann man Function haben ... aber nur die PostgreSQL Function also nichts mit xBase

Code: Alles auswählen

   CREATE INDEX test1_lower_spalte1_idx ON test1 (lower(spalte1));
es gibt eine Menge Function welche das selbe machen wie xBase

allerdings muss man dann bei nachfolgenden Qwery ebenso verfahren

Code: Alles auswählen

   SELECT * FROM test1 WHERE lower(spalte1) = 'wert';
aber auch hier meine Frage an was du "denkst" und ob es in SQL "ohne" geht :?:
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

wenn man nun den "bearbeitete" Indexkey() in einem Array und die Table hat geht es an die Reihenfolge der Indexe.

Code: Alles auswählen

   OrdSetfocus( [<cTagName>|<nIndex>] ) 
daraus mach ich nun

Code: Alles auswählen

   oPg:OrdSetfocus( [<cTagName>|<nIndex>] )
die Method dazu sieht so aus

Code: Alles auswählen

METHOD JimBrowse:OrdSetfocus(xValue)
LOCAL cOrder := ""
LOCAL nPosi

   IF Valtype(xValue) = "N"
      cOrder := aIndex[xValue][AUSDRUCK]

   ELSEIF Valtype(xValue) = "C"   
      nPosi := ASCAN(aIndex, { |o| o[TAGNAME] = xValue } )
      IF nPosi > 0
         cOrder := aIndex[nPosi][AUSDRUCK]      
      ENDIF
   ENDIF

   IF !EMPTY(cOrder)
      ::NextCursor(,,, cOrder,, )
   ENDIF
RETURN
damit kann man unter PostgreSQL den "Kontrollierenden Index" einstellen

---

der Kern für die "Navigation" steckt in der Method NextCursor()

Code: Alles auswählen

METHOD JimBrowse:NextCursor( cTable, cField, cWhere, cOrder, cLimit, cOffset )
...

   DEFAULT cTable TO ::_cTable
   DEFAULT cField TO ::_cField
   DEFAULT cWhere TO ::_cWhere
   DEFAULT cOrder TO ::_cOrder
   DEFAULT cLimit TO ::_cLimit
   DEFAULT cOffset TO ::_cOffset

   IF ( ::_cLastTable <> cTable .OR. ::_cLastOrder <> cOrder )
über den OFFSET kann man ISAM Befehle wie SKIP simulieren

das SELECT verpackt man in einen CURSOR und ab Server 9 kann man die PostgreSQL Function row_number() mit einbauen.
row_number() ist eine neue Column im Result-Set und enthält die relative Satznummer ( -> DbPosition) einer Sortierung.

Code: Alles auswählen

   cVar1 := "BEGIN WORK;"

   IF SP_nVersion() < 9  // Server Version
      cVar2 := "DECLARE MyCursor CURSOR FOR SELECT " + cField +;
              " FROM " + cTable + ;
              IF( EMPTY( cWhere ), "", " WHERE " + cWhere ) + ;
              " ORDER BY " + cOrder
   ELSE
      cVar2 := "DECLARE MyCursor CURSOR FOR SELECT " + cField +;
               ", row_number() OVER (ORDER BY " + cOrder + ")"+;
               " FROM " + cTable + ;
               IF( EMPTY( cWhere ), "", " WHERE " + cWhere ) + ;
               " ORDER BY " + cOrder
   ENDIF

   cVar3 := "MOVE  FORWARD " + cOffset + " IN MyCursor"
   cVar4 := "FETCH FORWARD " + cLimit  + " FROM MyCursor"
   cVar5 := "CLOSE MyCursor;"
   cVar6 := "COMMIT WORK;"
das nun die 6 Strings die hintereinander als Qwery abschickt werden.

Code: Alles auswählen

   ::oPG:exec( cVar1 )
   ... 
   IF ResultStatus( ::oPG, ::_Post2Loop )
      ::oPG:exec( cVar2 )
      ... 
      IF ResultStatus( ::oPG, ::_Post2Loop )
         IF VAL( cOffset ) > 0
            ::oPG:exec( cVar3 )
            ... 
            IF ResultStatus( ::oPG, ::_Post2Loop )
               oRes := ::oPG:result
            ENDIF
         ENDIF
         ::oPG:exec( cVar4 )
         IF ResultStatus( ::oPG, ::_Post2Loop )
            ...
         ENDIF
      ENDIF
   ENDIF
   ::oPG:exec( cVar5 )
   IF ResultStatus( ::oPG, ::_Post2Loop )
      ... 
   ENDIF
   ::oPG:exec( cVar6 )
die Zugriffszeit der jeweiligen ::oPG:exec() muss man mit dem HrTimer messen da die bei < 1/100 Sek. liegen :!:
... wenn man nicht ein riesiges LIMIT wählt [-X

Anmerkung : der "Inhalt" der Strings wird hier nicht überprüft was gewisse Sicherheitsstands nicht erfüllt wie Carlo hinwies.

---

aus xBase ist man gewohnt alle Daten im Zugriff zu haben aber ein Bildschirm kann nur eine begrenzte Anzahl anzeigen.
es reicht also das LIMIT auf die Anzahl der möglichen Zeilen einzustellen und per "DbSkipper" weitere anzufordern.

einen umfangreichen "DbSkipper" braucht man nicht weil man zur akuellen Position nur +/- nSkip "berechnen" muss für die neue OFFSET Position.
damit ist die "Navigation" mit dem Keyboard oder dem extern Scrollbar einfach.

---

Zwischenfazit :

ohne "Optimierung" bestehenden Source wird es nicht gehen. [-X

wenn man nun sein Konzept Richtung Dbserver() erweitert dann hätte man eine sehr gute Grundlage für eine SQL CLASS mit den selben Namen für die Method(en)

statt die DBE zu tauschen würde man die CLASS wechseln aber der Effekt wäre der gleiche :!:
Theoretisch könnte man eine CLASS mit einen eigenes Datenformat haben und mit den selben Method(en) navigieren.

eine ISAM Emu zm "navigieren" ist auch bei BTREE nicht notwendig. Tatsächlich wird BTREE um so schneller je grösser die Datenmenge ist.
eine "Navigation" über den OFFSET ist (relative) langsam aber sie "kostet" weniger als die Pflege der internen Index FIELD

die Reduktion der "Kosten" merkt man an der gestiegenen Performance =D>
also "unnötiges" streichen wenn man es anderes "günstiger" das selbe Ergebnis erzielt :!:

---

Ich möchte euch bitten Fragen zunächst zu dem vorgestellten erweiterten native Konzept zu machen.
wo seht ihr noch Probleme das es mit eurem Source nicht "passt" (Express++ ... wohl per ODBC) :?:
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

es wurde der "Verdacht" geäussert das ich eine DLL / LIB für Xbase++ liefere ... aber die Arbeit mache ich mir NICHT [-X

meine Intention ist das wir GEMEINSAM eine solche DLL / LIB entwickeln wobei ich gerne beitrage.
der Source einer CLASS wäre nicht Version abhängig ... und ggf. auch für andere Sprachen (harbour) geeignet

die Code Beispiele, aus meinen funktionierenden Apps, sind lediglich dafür gedacht zu zeigen das man die internen Index FIELD nicht benötigt :!:

bislang wurde meine Frage nach einem Fall wo man die internen Index FIELD benötigt nicht beantwortet ... es "reicht" eben zu 98%

natürlich gibt es auch Problem wie mit einer UDF "im" xBase Index.
Frage : kann Xbase++ v2.x einen Index mit UDF "upsizen" :?:
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: PostgreSQL native

Beitrag von ramses »

Hallo Jimmy
Frage : kann Xbase++ v2.x einen Index mit UDF "upsizen" :?:
Das geht doch überhaupt nicht. Das liegt aber nicht an xbase. Sondern weil PG kann keinen xbase Code in Form einer UDF ausführen.
meine Intention ist das wir GEMEINSAM eine solche DLL / LIB entwickeln wobei ich gerne beitrage.
der Source einer CLASS wäre nicht Version abhängig ... und ggf. auch für andere Sprachen (harbour) geeignet
Für mich würden da bereits 2 Punkte nicht passen: den Code als DLL und "nicht Versionsabhängig" auch noch für Harbour zu bauen.
Beides führt zu zuviel Problemen und Aufwand.

Ich habe meine "Toolbox" für PG momentan zusammen. Das benötigt einige Umbauarbeiten und Test's des Codes aber die Performance passt perfekt.
Für meinen Anwendungszweck brauche aber auch viele Dinge von denen du schreibst gar nicht.
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

ramses hat geschrieben: Di, 09. Jul 2019 20:16 Das geht doch überhaupt nicht. Das liegt aber nicht an xbase. Sondern weil PG kann keinen xbase Code in Form einer UDF ausführen.
mit der UDF wollte ich darauf hinaus das man so was nicht einfach nach SQL übertragen kann.
wenn überhaupt müsste man mit PostgreSQL Function arbeiten
ramses hat geschrieben: Für mich würden da bereits 2 Punkte nicht passen: den Code als DLL und "nicht Versionsabhängig" auch noch für Harbour zu bauen.
Beides führt zu zuviel Problemen und Aufwand.
mit Version unabhängig ist Xbase++ gemeint denn der SQL Server spielt erst mal keine Rolle.

mit dem Zusätzlichen Wunsch nach harbour sag ich nur aus das ich mit dem "kleinsten" gemeinsamen Nenner für die Schnittstelle erarbeiten möchte. es gibt kaum Stellen im native Code der unter harbour eine andere Syntax verlangen würde.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

zur libpq.dll eine Bemerkung : es ist für diesen Thread egal welche libpq.dll Version man verwendet. :!:
die zusätzlichen DLL in der v9.x Version sind z.b. für Verschlüsselung was ich zunächst nicht beachte.

der Unterschied bei Einsatz kommt durch die verwendete Qwery.

ich hab die "lates" LFUPDR deshalb mit der "Original" libpq.dll von Phil Ide laufen, also der v8.x
mit dem v9.5 Server kann ich trotzdem in der Qwery die v9.5 Befehle/Function wie ROW_NUMBER() verwenden.

wie schon gesagt gehe ich von der Original CLASS von Phil Ide aus wie man da die nächsten Schritt machen kann.

---

nachdem das Grundgerüst soweit vorhanden ist kommen wir zum Thema Qwery selbst.

wenn ich eine Auswahl von DBF Dateien erstellen will reicht DIRECTORY() um die Informationen zu bekommen.
unter SQL bring eine DIRECTORY() nichts. unter PostgreSQL verwende ich diese Qwery

Code: Alles auswählen

   // select 'public' Tables
   //
   ::cQuery := "SELECT table_name FROM information_schema.tables " + ;
               "WHERE table_schema = 'public'"
in Result-Set erhalte ich alle Table Namen

die PostgreSQL Server Version erhält man so

Code: Alles auswählen

      // PostgreSQL Version
      //
      ::cQuery := "SELECT version()"
nach dem öffnen einer Table empfehle ich zunächst diese Qwery

Code: Alles auswählen

   ::cQuery := "SELECT * FROM %1 LIMIT 1"
damit erhalte ich aus dem Result-Set

Code: Alles auswählen

  IF ::oPG:Exec( ::cQuery )
      ::oR_Fields := ::oPG:result
      ::nRows := ::oR_Fields:rows
      ::nCols := ::oR_Fields:cols
die Anzahl der ROW und COL z.b. für ein Browse

es gibt noch eine Qwery von Edgar die ich nicht benutze

Code: Alles auswählen

   ::oPg:exec( "SET datestyle to SQL, DMY" )

damit hat man nun die benötigten Informationen über die Table
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

es gibt eine neue PDR 7146 wo über ein Problem mit PgDBE ISAM Emu und OrdSetFocus() gesprochen wird.
mal sehen sie lange Alaska dafür braucht da zunächst kein Workaround angegeben wird ....

erinnert Ihr euch an die Letzte Zeile im Code-Snip von NextCursor()

Code: Alles auswählen

   IF ( ::_cLastTable <> cTable .OR. ::_cLastOrder <> cOrder )
dies ist genau der Fall der mit der PDR 7146 wenn man es nicht berücksichtigt was Alaska wohl "übersehen" hat. (kein Kommentar)

es hat nichts mit "Schlaumeierei" zu tun wenn man Erfahrungen gemacht hat aber andere noch nicht.
aber um nicht den "Schlaumeier" zu spielen werde ich die Erfahrung NICHT mit euch teilen ... die Lösung ist zu einfach :badgrin:

Tip : "Think SQL"
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: PostgreSQL native

Beitrag von ramses »

AUGE_OHR hat geschrieben: Di, 09. Jul 2019 22:30 mit dem Zusätzlichen Wunsch nach harbour sag ich nur aus das ich mit dem "kleinsten" gemeinsamen Nenner für die Schnittstelle erarbeiten möchte. es gibt kaum Stellen im native Code der unter harbour eine andere Syntax verlangen würde.
Hallo Jimmy

meine Liste für den kleinsten gemeinsammen Nenner oder besser Kill-Kriterien beginnt so:
- PostgreSQL Server Version 11.4 oder 12 Beta
- libpq.dll Version 11 oder höher
- Xbase++ Version 2.00.1113 und folgende
....
....

ohne das Einhalten dieser ersten 3 MInimalanforderungen ist jede Entwicklungsarbeit für ein aktuelles Tool, mit dem künftig gearbeitet werden soll, Sinn und Zwecklos nur schon die Zeit ist zu Schade um darüber zu diskutieren. (Weil es ja dann wegen den Kill-Kriterien, die nicht alle erfüllen wollen, nie umgesetzt wird. Ein Tool sollte aber zum Entwickungszeitpunkt in allen Punkten so aktuell wie nur irgendwie möglich sein. Es altert dann schon genug schnell.)
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

hi Carlo,
ramses hat geschrieben: Mi, 10. Jul 2019 6:30 meine Liste für den kleinsten gemeinsammen Nenner oder besser Kill-Kriterien beginnt so:
- PostgreSQL Server Version 11.4 oder 12 Beta
- libpq.dll Version 11 oder höher
- Xbase++ Version 2.00.1113 und folgende
ich sehen keine Widerspruch, deine 3 Punkte würden doch erfüllt.

a.) dem Source ist es egal ob v1.9x oder v2.x denn es geht nur um die native Schnittstelle wo man nur DLL Aufrufe benutzt.
b.) die PostgreSQL Server Version sollte > 9.4 sein. ob v10, v11 oder v12 wäre egal für den Client.
c.) die libpq.dll kann die alten v8.x sein WENN man nicht Verschlüsselung & Co benötigt wobei ich (noch) nicht weiss wie man da ran kommt denn das beinhaltet der Wrapper von Phil Ide nicht.

wie man dann mit dem Result-Set umgeht (Array oder DataObject) wäre eine andere Sache aber die Qwery wäre für beide gleich.
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: PostgreSQL native

Beitrag von Jan »

Jimmy,

bei dem Problem der Xbase++-Version übersiehst Du aber was: Du könntest das sicher auch so schreiben, daß das unter Clipper laufen würde (übertrieben ausgedrückt). Ob das sinnvoll ist, weil Du dann viele Möglichkeiten von Xbase++ nicht nutzt, die Clipper nicht bietet, sei aber mal dahin gestellt. Das Gleiche gilt auch für die 2.0. Die ist so massiv mit SQL-Funktionen erweitert worden gegenüber der 1.9, das so manches, das DU mit 1.9 umsetzt, einfach nur eine Krücke wäre. Von daher ist die Anforderung von Carlo "Xbase++ Version 2.00.1113 und folgende" nicht ganz unberechtigt.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

hi,

das die native Schnittstelle unter v1.9.355 oder einer anderen Sprache funktioniert ist die Möglichkeit für Leute die NICHT auf die V2.x umsteigen wollen aber trotzdem mit dem PostgreSQL oder MySQL Server arbeiten möchten.

ich habe mich auf native PostgreSQL konzentriert während Georg mit native MySQL dir sicherlich einiges erzählen könnte.

was du als "SQL-Funktionen" bezeichnest betrifft die PgDBE und den Client und über die Geschwindigkeit gibt es wenig neues zu berichten. echte SQL-Functionen sind von der PostgreSQL Server Version abhängig und so lange Alaska noch den v8.3 Server ausliefert sind spätere SQL-Functionen sinnlos da der Server die nicht versteht [-X

ich habe in der v10, v11 und v12 keine neuen Function gefunden die mir unter xBase helfen.
Aus Sicherheits-Aspekten sollte man natürlich mit einer aktuellen Server Version arbeiten.

ich habe die Darkmode Version von PGU mit der v8.3 libpq.dll, die immer noch mit einem aktuellen 32/64 Bit PostgreSQL Server "kommunizieren" kann, mitgeliefert da es "reicht". die weiteren DLL ab v9.x sind ja für Verschlüsselung gedacht.
btw. es gibt ja keine 32 Bit v12 Version also auch keine weiter DLLs die man mit 32 Bit Xbase++ verwenden kann.

Wenn Alaska die Verschlüsselung bringen sollte, mit PostgreSQL > 9.5, DANN kannst du es gerne noch mal versuchen mich zu "überzeugen" :badgrin:

wie schon gesagt ist unter SQL alles eine Frage der Qwery ... und viele (überflüssige) Qwery machen ein System langsam.
das "pflegen" der internen Index FIELD ist jedesmal eine Qwery und der ganze Overhead ist
NICHT NOTWENDIG unter SQL
deshalb sag ich die ganze Zeit "think SQL" wenn man mit dem SQL Server am Client arbeitet.
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: PostgreSQL native

Beitrag von Jan »

Jimmy,

- ich rede NCIHT von Qwery (was immer das sein soll, vermutlich kenne ich zu wenig SQL um das zu verstehen. Ich kenn nur Query, aber da Du das permanent anders schreibst meinst Du vermutlich was anderes)
- ich rede NICHT von Indizes
- ich rede NICHT von PGDBE
- ich rede NICHT von Darkmode (was auch immer das mit SQL zu tun haben sollte, aber da Du das zu diesem Thema einwirfst muß es ja damit zusammen hängen)
- ich rede NICHT von bestimmten PostgreSQL-Versionen, nicht mal von bestimmten SQL-Servern

Ich rede von SQL-Funktionen, die unabhängig vom verwendeten SQL-Server funktionieren. Und die die 1.9 einfach noch nicht (in dem Umfang) kennt.

SQL in 2.0 meint bei Weitem nicht immer nur PostgreSQL oder gar PGDBE. Sondern geht viel weiter.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

Jan hat geschrieben: Do, 11. Jul 2019 11:13 Ich rede von SQL-Funktionen, die unabhängig vom verwendeten SQL-Server funktionieren.
Der Server versteht KEIN xBase also redest du über Sachen auf der Ciient Seite.

die Client Seite sendet eine Qwery ( = Anfrage ) und der Server antwortet.
der Client muss die Daten dann mittels Result-Set abholen und aufbereiten

Code: Alles auswählen

INTO DataObject
oder

Code: Alles auswählen

INTO ARRAY
macht vom Resultat keinen Unterschied.

---

solltest du "neue" Controls für SQL meinen hab ich auch noch was : Dynamische Anzeige für "Browse"
ich hole nur Daten ich welche die Anzeige benötigt. welche Daten benötigt werden bestimmt die Anzeige :!:
Jan hat geschrieben:Und die die 1.9 einfach noch nicht (in dem Umfang) kennt.
die v1.9 kennt kein SQL.
nur mit SQLexpress++ (ODBC) oder eben native die DLL ansprechen.
Jan hat geschrieben:SQL in 2.0 meint bei Weitem nicht immer nur PostgreSQL oder gar PGDBE. Sondern geht viel weiter.
das ist aber nicht das Thema von diesem Thread [-X (= NO) sondern native Schnittstelle unter Xbase++ (egal welche Version)
gruss by OHR
Jimmy
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: PostgreSQL native

Beitrag von Jan »

Jimmy,

ich gebs auf. Mach was Du willst, egal wie unsinnig das letztendlich ist. Sind ja Deine Zeit und Deine Nerven. Da Du der einzige hier im Foum bist, der SQL wirklich versteht, wirst Du schon wissen, was Du da machst.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL native

Beitrag von AUGE_OHR »

Jan hat geschrieben: Do, 11. Jul 2019 11:53 ich gebs auf. Mach was Du willst, egal wie unsinnig das letztendlich ist. Sind ja Deine Zeit und Deine Nerven.
gut so dann störst du nicht mehr den Thread
Jan hat geschrieben:Da Du der einzige hier im Foum bist, der SQL wirklich versteht, wirst Du schon wissen, was Du da machst.
ES REICHT
gruss by OHR
Jimmy
Antworten