Inoffizielles deutsches Xbase-Forum

Servus Werner,
da kommen wir ja wieder zu meinem Thread, in dem ich danach fragte, ob und wenn ja wer, jedesmal die Connection öffnet und dann sofort wieder schließt. Worauf da die Mehrheit (meiner Erinnerung nach) antwortet, am Anfang öffen und am Ende erst schließen). Die Connection wird einmal bei Programmstart geöffnet und dann bleibt sie solange auf, bis das Programm beendet wird. Ich glaube nicht das sowas eine gute Lösung wäre, wenn immer wieder User auf den ADS zugreifen und jedesmal die Connection geöffnet und dann wieder geschlossen wird.

Servus Manfred,

richtig, die Antworten dazu wurden schon gegeben. Mein Post bezog sich auf die 2malige Aussage:

Aber die Doku gibt nichts her

Mit dem :disconnect() dürften auch beim ADS (ich kanns nur für den PG bestätigen) die Tabellen geschlossen werden. Ansonsten ist es doch Sache des SQL-Servers, was er wielange geöffnet hält. Der SQL-Server kümmert sich schon drum und schaut, dass alles gut performant abläuft.

Die 3 Beispiele in der Doku erklären doch die grundsätzliche Vorgehensweise für den Connect, Abfrage und das Schließen der Session.

Hi Werner,
das ist ja jetzt unsere Frage. Ist das die absolute Aufgabe vom Server, oder aber läuft hier was falsch? Die Liste knallt sich total voll. Mich wundert nur, das es noch keinem anderen aufgefallen ist. Also gibt es für mich derzeit nur 3 Schlußfolgerungen:
1) keiner hat ein Programm im 24/7 Betrieb
2) keinem ist es bisher aufgefallen.
3) irgendwie wurde was falsch programmiert von mir.

Die Beispiele in der Doku beschreiben nur einen Vorgang. Und deshalb sieht es so aus, als wenn geöffnet, gearbeitet, geschlossen wird. Ich denk mal, das ist nur ein Hinweis darauf, das es nicht vergessen werden soll/darf

Das Problem und die fehlende Doku beziehen sich:

Code: Alles auswählen

       oStmt  := DacSqlStatement( oSession ):fromChar( cStatement )
       cAlias := oStmt:Build():Query()
       dbselectarea(cAlias)
       (cAlias)->(DBGOTOP())
       (cAlias)->(DBCLOSEAREA())

Hier scheint das Handle im ADS Server nicht geschlossen zu werden. Im Hintergrund werden ja auch 2 Handles für die Abfrage erzeugt:
- eins für die Initialisierung der SQL Connection
- noch eins für die Ergebnisdaten.
DbCloseArea() schliesst wohl nur das letzte, fehlt: oStmt:destroy() als Methode

Hallo Markus,

das habe ich gerade eben eingebaut mit dem Ergebnis, dass eine Fehlermeldung kommt. Methode ist für dieses Objekt unbekannt.

Servus Markus,

unter PG sehe ich in so einem Fall genau eine Connection. oStmt nutzt ja nur das Connection-Handle zur Kommunikation (senden und empfangen von Befehlen / Daten). Das erzeugt am PG-Server keine weitere Verbindung. oStmt ist i. d. R. eine lokale Variable und wird doch am Ende der Procedure / Threads gekilled.

Nach meinem Verständnis ist alles, was man für den SQL-Server braucht, ein erfolgreicher Connect, den man irgendwann wieder schließt. Um alles andere kümmert sich doch der SQL-Server.

Servus Manfred,

was genau ist jetzt Dein Problem mit dem ADS? Hast Du ein :disconnect() drin und danach bleiben Verbindungen, Handles, Tabellen offen, obwohl keine andere Verbindung (auch von einem anderen Client / Benutzer / Thread) mehr existiert?

Hallo Werner
ADS: Hier wird ja mittels der C-API gearbeitet, sowohl ADSDBE wie AdsClass. Und dazu gibt es 2 Layer: einen für die SQL Kommunikation und einen für das Resultset. Beise müssen geschlossen werden. Ich kann ja mit einer Connection beliebig viele Tabellen öffnen oder SQL Abfragen erstellen. Gleichzeitig.

PG: Auch hier kann ich mit einer Connection beliebig viele SQL Abfragen erzeugen, die Connection ist einmalig je App und bleibt solange offen.

Hallo Werner,

durch ein :disconnect() werden alle geöffneten Dateien geschlossen. Das ist auch nicht das Problem.

Code: Alles auswählen

oStmt  := DacSqlStatement( oSession ):fromChar( cStatement )
cAlias := oStmt:Build():Query()
dbselectarea(cAlias)
(cAlias)->(DBGOTOP())
(cAlias)->(DBCLOSEAREA())

Nach diesem dbCloseArea() ist aber die geöffnete Datei im ADS noch offen. Und jedesmal nach einem SQL-Befehl die Connection zu schliesen, ist doch bestimmt ein großer Zeitverlust.

Servus Marcus und Bertram,

aber das oSession:disconnect() löscht doch die Verbindung / das Handle und schließt auch die Dateien am Server.

Wenn vor dem :disconnect() die Dateien auf dem SQL-Server offen bleiben, stört das doch niemanden? Mit DbCloseArea() wird ja in beiden Fällen (ADS und PG) nur das Result-Set / die temporäre DBF im lokalen Arbeitsspeicher des Client geschlossen.

Nochmal: Wo ist das Problem beim SQL-Server?

Manfred will ja kein Session:disconnect() machen, weil sonst müsste er ja nach jedem SQL eine :disconnect und dann wieder ein :connect machen.
Das wäre ein Workaround, aber nicht die Lösung.

Bei PG mag ein dbclosearea ausreichen. Da ist die API anderst strukturiert

Genau Marcus

jawoll

Das ist ein Webserver und der hat eigentlich andauernd Traffic. Und da möchte ich nicht wissen, was passiert, wenn man andauerend connected und disconnected.

Bei Postgres muss bei der Arbeit mit der DLL ein Resultset mit PQclear( nResultHandle ) geschlossen werden. Sonst bleiben auch alle geöffnet.
Vielleicht ist es bei ADS auch so.....

Manfred: Du wirst es, glaub ich, nicht merken, dauernd connect / disconnect, trotzdem keine Lösung.
Bin auf Alaska gespannt
Hab leider keine Testumgebung, um das auchmal zu analysieren

Ramses: genau so ein PQclear fehlt....

Das Beispiel von Bertram haben sie schon. Mal sehen, was passiert.

Marcus Herz hat geschrieben: ↑Fr, 29. Mai 2020 17:26 Ramses: genau so ein PQclear fehlt....

Wenn du das Statementhandle hast wäre doch dies die Lösung:

AdsCloseSQLStatement ( ADSHANDLE hStatement )

Remarks
All statement resources are released. If tables were opened during generation of the rowset, they will be closed.
If a cursor associated with this statement exists it is freed as well.
To close a cursor without releasing the statement handle, use AdsCloseTable on the cursor handle.

Bertram Hansen hat geschrieben: ↑Fr, 29. Mai 2020 12:57 Hallo Carlo,

ich antworte mal für Manfred, weil wir beide uns damit aktuell rumschlagen.
Es geht nicht darum ein anderes Tool einzusetzen, sondern darum warum das beim ADS nicht funktioniert. Nur darum!!!!!

Bist du dir sicher, dass es mit PostgreSQL keine Probleme gibt?
Kannst du mal ein wenig Code zeigen, wie du das mit DacSqlStatement() realisiert hast?

Ach so. Es geht euch nur um das warum.....

Ja, ich bin mir sicher dass es mit PG keine Probleme gibt. Jedenfalls in meiner Anwendung.
Mit xb2net habe ich einen Web-Server am laufen der 50-100 Anfragen / Sek mit PG als Datenbank abarbeitet.
DacSqlStatement() verwende ich nicht. Ich wurde damit nicht Glücklich. Mit der Web-App hatte ich ganz andere Anforderungen an die Datenbankschnittselle das ging mit guter Performance nur mit API Aufrufen. Also natives PG.
Im Stil:

Code: Alles auswählen

::nResult     := PQexec(::nConn, cExec )

// DLL libpq XIMPORT HANDLE     PQexec(HANDLE conn, LPSTR cQuery)

Du musst dich dabei aber selbst um alles kümmern.

Hallo Carlo,

das stimmt wenn ich AdsCloseSQLStatement ( ADSHANDLE hStatement ) einbauen würde, dann "dürfte" das Problem nicht mehr auftreten.
Aber über die normale Xbase++ Möglichkeiten steht darüber nichts in der Doku.

Ich habe jetzt noch eine andere Sachen ausprobiert. Ich habe auch das Tool von Roger Donnay (der Quellcode ist ja immer dabei). Roger hat auch für ADS eigene Tools geschrieben. Unter anderem gibt es bei Roger in seiner Klasse DC_AdsStatement() die Methode Close(). Und genau da werden die beiden ADS Funktionen:
AdsCloseTable(::CursorHandle)
AdsCloseSQLStatement(::StatementHandle)
aufgerufen.
Wenn ich Roger Tools verwende, dann wird die Tabelle nach der Methode Close() geschlossen.

Genauer gesagt, habe ich zum Test jeweils eine Schleife mit 5 Durchgängen gemacht. Mit den Xbase++ Befehlen wird immer eine neue Tabelle hinzugefügt und bleibt geöffnet und mit den Tools von Roger bleibt es immer nur bei einer Tabelle die geöffnet ist.

Erst mir disconnent() werden alle Tabellen geschlossen.

Hallo Bertram

da hast du ja die Lösung gefunden. Roger hatte ganz sicher seine Gründe diese Klasse zu schreiben ..........

Hallo Carlo,

ich bin mal gespannt, was Alaska dazu sagt. Nicht jeder hat das Tool von Roger.

Marcus Herz hat geschrieben: ↑Fr, 29. Mai 2020 17:19 Manfred will ja kein Session:disconnect() machen, weil sonst müsste er ja nach jedem SQL eine :disconnect und dann wieder ein :connect machen.
Das wäre ein Workaround, aber nicht die Lösung.

Das hab ich damit auch nicht sagen wollen.

Ich darf nochmal fragen:
Bertram und Manfred, was genau ist euer Problem, dass der ADS bis zum :disconnect() - vermutlich aus Performance-Gründen - Tabellen offen lässt?

Werner
der ADS lässt die Tabellen offen, weil die ADSDBE diese nicht komplett schliesst

und führt zu welchem Problem?

Inoffizielles deutsches Xbase-Forum

Remote Server Info [ERLEDIGT]

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info

Re: Remote Server Info