Inoffizielles deutsches Xbase-Forum

Die C# Anwendungen sollten als möglichst reine SQL-Anwendungen gehalten werden, ohne Bezug auf ISAM-Konzepte. Die C# Anwendungen sollten z.B. nicht wissen müssen, welche Spalten in ISAM-Indexen benutzt werden in unserer Hauptanwendung.

Zu diesem Thema gibt es ein paar gute Beiträge in ILX, z.B:
https://ilx.alaska-software.com/index.p ... essing.48/
https://ilx.alaska-software.com/index.p ... nd-sql.82/

SQL SELECT ist wenig problematisch (solange __delete berücksichtigt wird), aber INSERT, UPDATE und DELETE Befehle könnten die für unsere Hauptanwendung essentielle ISAM-Emulation stören oder zumindest unerträglich verlangsamen.

Mir schwebt es vor, in Xbase++ eine Zwischenschicht (DLL) zu schreiben, die Funktionen für Verbinden/Login, Trennen, SELECT, UPDATE, INSERT und DELETE Befehle möglichst nahe an der SQL-Syntax implementiert (z.B. mit Syntaxteile wie WHERE-Klausel als einzelne Parameter). Falls irgendwann die ISAM-Emulation nicht mehr nötig wäre, dann könnte die Zwischenschicht leicht durch echte SQL ersetzt werden, so die Idee.

Ich nehme an, ich sollte dafür eine Static DLL erzeugen: Verstehe ich richtig, dass dann nur diese eine DLL an die C# Entwickler weitergegeben werden muss (und nicht die ganze Xbase++ Runtimes)?
Leider habe ich bisher sehr wenig Dokumentation zum Thema "DLL erzeugen" gefunden, und z.B. welche Parameter-Konventionen benutzt werden.
Hat jemand Erfahrung mit der Erzeugung solcher DLLs, oder mit dem Thema "Schreibzugriff auf pgdbe Datenbank aus anderen Sprachen"?

P.S.
Die pgdbe ISAM-Emulation bleibt gesetzt für unsere Hauptanwendung für die vorhersehbare Zukunft (Schätzungsweise mindestens noch 10 Jahren), also es ist wichtig für uns, den Zugriff aus anderen Sprachen so zu regulieren, dass die Hauptanwendung nicht beeinträchtigt wird. Lösungsansätze ohne pgdbe wären also nicht relevant für diese Post.

Wenn ich dich richtig verstehe, willst du eine in Xbase geschriebene DLL an C++ Anwendung zur Verfügung stellen. Das geht nicht, weil die DLL dazu die Xbase++ Runtime laden müsste. Soweit ich weiß, gibt es da einen Trick, frag dazu direkt bei Alaska nach. Ist in der Tat ein Lizenzproblem.

Danke Marcus,

C++ wäre auch eine Möglichkeit bei uns, wobei C# viel geeigneter wäre für eine klassische Datenbankanwendung. So ein Lizenzproblem hätte ich aber nicht erwartet. Ich weiß, dass in der Lizenz es eine Schutzklausel gibt, um zu verhindern, dass jemand Xbase++ benutzt um im Effekt Xbase++ als Entwicklungswerkzeug weiterzugeben, das ist ja auch fair. Aber in diesem Fall?

Jedenfalls Danke für den Tipp, das werde ich mit Alaska klären.

Hallo David !

Vielleicht hilft das: https://www.xbaseforum.de/viewtopic.php?t=11233

Hallo Hans-Peter,

vielen Dank für das Link, den Thread hatte ich bei meiner Suche nicht gefunden!

An eine COM-Schnittstelle hatte ich bisher nicht gedacht, es klingt etwas aufwändiger, aber ist eine sehr interessante Alternative falls der Direktaufruf nicht geht: Dazu habe ich erstmal eine Anfrage an Alaska Support gemacht...

Bau doch in Xbase++ eine Schnittstelle den du als Dienst installierst der über TCP/IP angesprochen werden kann ....

Danke Carlo!

Das wäre auch theoretisch möglich, obwohl ich bisher keinerlei TCP/IP-Kommunikation mit Xbase++ gemacht habe (nur indirekt über pgdbe).
Ich könnte mir auch eine HTTP Schnittstelle vorstellen, vielleicht als REST.

Bisher tendiere ich leicht zu HaPes Idee mit COM (bzw. DDE, ActiveX, .NET oder wie auf immer es nächstes Jahr heißt ).
Es fällt mir nämlich gerade ein, dass wir Leute haben, die MS Access benutzen und für die eine Schreib-Schnittstelle zur Hauptdatenbank nützlich wäre.
COM habe ich auch bisher nur von einem C++ Client (für OPC) benutzt, also ein Xbase++ Server wäre für mich Neuland, aber es ist verlockend...

Ich bin aber noch offen für alles, die Möglichkeiten gehen mir alle durch den Kopf.

Hallo David,

aaaaaalso, da würden mir einige Dinge in den Kopf kommen, wie man da am besten vorgehen könnte, ja sogar sollte.
Ich gestehe aber, dass eine Xbase++ DLL (bitte macht das nicht; nicht wegen Lizenzproblemen, sondern weil das technisch nicht geht/gehen soll) oder auch Xbase++ als COM nicht zu den Ideen gehört. Ich es sogar falsch fände.

Aber ich finde deine Frage sehr interessant.

Also habe ich mich mit meinen Kollegen zusammengesetzt und wir haben kurzerhand im ILX Portal noch ein weiteres Forum freigeschaltet. Melde dich mal dort an, Tech & Talk, PostgreSQL und dann stelle doch mal deine Frage dort. Das Schöne, es wird von Alaska beantwortet werden und dient somit auch allen anderen aktiven Subskriptionskunden. Nur eine Bitte: frage bitte auf English. Ich hoffe, das geht in Ordnung.

Naaaaa?

Grüße
Frank

Hallo Frank,

das habe ich natürlich sehr gern gemacht!
Als alter Englander kann ich die Sprache immernoch ein bisschen...

https://ilx.alaska-software.com/index.p ... xbase.123/

Hallo David,

dann DANKE an den alten Englander
Die (Alaska)Jungs werden sich dann schon draufstürzen. Intern haben wir uns schon ausgetauscht.
Danke für die Anfrage. Wir wollen dieses Medium jetzt mal so nutzen. Wir sind selbst gespannt, ob es funktioniert.

Grüße
Frank

hm,
schafft ihr es euch da anzumelden? Mein ACcount ist angeblich nicht vorhanden. Ich sehe auch nirgends eine Registriermöglichkeit....

Hallo Manfred,

ich habe extra für dich nachgeschaut: du bist angelegt. ILX kennt dich
Gehe auf die Option Passwort vergessen und generiere für dich dein Passwort und dann komm'schd noi.

Grüße
Frank

Guten Morgen David,

dtmackenzie hat geschrieben: ↑Do, 23. Feb 2023 17:10 https://ilx.alaska-software.com/index.p ... xbase.123/

Kriegst du eigentlich eine Benachrichtigung, dass eine Antwort da ist?
Nun denn, wir haben dir dort geantwortet. Versucht zu antworten.

Grüße
Frank

Frank,
ich komme mit meinen daten da auch nicht rein.

Hallo Frank !

Warum dürfen nur Entwickler mit aktiver Subscription ins ILX-Forum?

Hallo Klaus,

Koverhage hat geschrieben: ↑Fr, 24. Feb 2023 9:44 ich komme mit meinen daten da auch nicht rein.

Ich habe auch dich nachgeschaut und dein Account ist angelegt und du solltest zugreifen können.
Was passiert denn? Hast du jemals ein Passwort angefordert (mit Passwort vergessen)?

Melde dich gerne auch bei uns, wenn du hartnäckig nicht reinkommst.

Gruß
Frank

Hi HaPe,

HaPe hat geschrieben: ↑Fr, 24. Feb 2023 10:45 Warum dürfen nur Entwickler mit aktiver Subscription ins ILX-Forum?

Das hat mehrere Überlegungen. Wir haben da auch noch nicht der Weisheit letzter Schluss.
Du kannst z.B. die Q&A durchforsten, ohne Anmeldung. Kein Problem. Und da sind wahnsinnig viele interessante Informationen. Jetzt schon. Und es werden immer mehr.

Das Forum haben wir gestern einfach mal so freigeschaltet. War so eine spontane Schnapsidee zu der Frage von David. Denn ILX kann weit mehr, als ihr gerade sehen könnt. Und da wird noch Einiges kommen.
Aber zum Beispiel wollen wir - wir haben uns intern dazu verpflichtet und versuchen das auch durchzuhalten - auf Fragen dort unbedingt eine Antwort geben. Wir wollen das auch moderieren. Sprich, wir werden versuchen - bitte nicht böse sein - Nonsens rauszuhalten, sogar zu löschen. Auch sollen keine ewig langen Threads entstehen mit Fragen, die das initiale Thema verlassen. Dann lieber eine neue Frage. Das wollen wir - so unser Gedanke - hartnäckig durchziehen. Es soll eine Wissensdatenbank werden. Wissen pur.

Und um das Ganze erst mal einzugrenzen (nicht zu viele Personen) und auch einen Mehrwert zu schaffen für eine Subskription, haben wir das erst mal nur für aktive Subskriptionen freigeschaltet. Das geht sogar so weit, dass wenn die Subskription ausgelaufen ist, dass man dann keinen Zugriff mehr darauf hat.

So sieht das heute aus. Wir überprüfen uns aber selbst und ILX wird sich immer weiter anpassen und ändern und erweitern.



Grüße
Frank

Hallo Frank !

Und um das Ganze erst mal einzugrenzen (nicht zu viele Personen) und auch einen Mehrwert zu schaffen für eine Subskription, haben wir das erst mal nur für aktive Subskriptionen freigeschaltet.

Das kann ich nachvollziehen.

Einen weiteren Gedanken dazu möchte ich gerne einwerfen.
Um neue Kunden zu erreichen, könnte ein zeitlich befristeter Zugang nützlich sein.

Da, wie du sagst

Auch sollen keine ewig langen Threads entstehen mit Fragen, die das initiale Thema verlassen. Dann lieber eine neue Frage. Das wollen wir - so unser Gedanke - hartnäckig durchziehen. Es soll eine Wissensdatenbank werden. Wissen pur.

das Ganze auf sehr hohem und hilfreichem Niveau ablaufen soll, könnte ein Testzugang einen neuen Kunden überzeugen zu bleiben.
Steht er vor verschlossener Tür, sieht er das xBase++-Paradies erst gar nicht und läuft einfach weiter ...
Und wer kauft schon die Katze im Sack

Moin HaPe,

da ist Alaska irgend wie in einer Zwickmühle. Auf der einen Seite soll das auch dem Support dienen, und den bekommt man ja nicht einmal mit jeder Subscription. Andererseits ist das natürlich ein toller Fundus, der durchaus meinungsbildend für (potentielle oder aktuell supbscriptionfreie) User sein kann.

Das Gute ist aber das Frank erklärt hat, das die mit ihrer Meinungsfindung noch nicht zu Ende sind. Und die aktuelle Freigabe spontan war wegen der Anfrage von David, obwohl die noch nicht durch sind mit ihrer eigenen Meinungsbildung zu dem Punkt. Ich bin mal gespannt worauf das noch hinaus läuft. Vielleicht gibt es ja irgend wann für Nicht-Subscription-Kunden die Möglichkeit für einen Read-Only-Zugriff. Oder freie Bereiche für jeden und gesperrte für Subscription-Kunden. Oder, oder, oder.

Wie auch immer - wenn Alaska da fundierte Infos und Code postet kann das nur hilfreich ein. Und wenn noch dann manches davon in die Hilfe und/oder die Samples einfließen könnte ...

Jan

Ich habe nun einige Fragen in ILX gestellt, die meisten mit diesem Thema verwandt.
Die bisherige Antworten sind sehr einleuchtende Erklärungen, insbesondere zu den strategisch/architekturellen Fragen, z.B:
Where best to implement business logic for new applications?
Writing to ISAM-Emulated databases from languages other than Xbase++

Meine derzeit dringendste Frage wäre:
Using SQL INSERT and UPDATE with ISAM emulating tables, in particular with indexed columns
Wobei "dringend" relativ ist, ich bin nun sowieso bald weg bis 13.3.23.
Falls das sich als möglich erweisen sollte, dann wäre das in meinem Fall eine vollständige Entspannung im kurz- bis mittelfristigen Zeitraum, das für sowohl "anderssprachige" Programmierer als auch Datenbankadministratoren gut brauchbar wäre.

Servus David,

schwierig, darüber bin ich auch gestolpert, hab den Fehler gemacht, einen Teil unserer Waren-Wirtschaft wg. einem Kunden auf ISAM-SQL umzustellen. Weil das bei größeren Datenmengen extrem langsam ist, musste ich einiges per Pass-Through machen, da ist die Geschwindigkeit dann ok. Aber, das ist so ähnlich, wie Deine Anforderungen - obwohl das ja trotzdem über die PGDBE läuft. Ich hab also munter Sätze eingefügt, geändert und gelöscht.

Danach passt dann nichts mehr! Z. B. werden dadurch die Such-Indexe aus dem Upsize nicht gepflegt, also die zusätzlichen Felder, die den Suchbegriff enthalten. Auch schmeisst das dann die recno() - Verwaltung durcheinander, wobei es hierzu eine Lösung gibt: https://ilx.alaska-software.com/index.p ... tables.70/

Die automatische Reparatur-Funktion der PGDBE mittels PGDBE_ISAM_ORD_CHECKANDFIX_KEYS funktioniert bei mir dann auch nicht - darüber stehe ich mit Alaska in Kontakt.

Um es einfach zu sagen: Externe Select-Abfragen sind gefahrlos

Hallo Werner,

DELETE sehe ich als etwas, wofür ich vielleicht sogar die Datenbankrechte den normalen Benutzern entziehen würde.
Soweit ich verstehe wäre es nur notwendig für PACK, was ich (wenn überhaupt) nur für Administratoren erlauben würde.
Der Regelfall wäre stattdessen __deleted zu setzen, damit kann ich gut leben.

INSERT und UPDATE sind etwas schwieriger. In der Praxis kommt es garantiert vor, dass Spalten, die in ISAM-Indexen vorkommen, bearbeitet werden müssen. Deshalb habe ich Alaska in ILX gefragt, ob es möglich wäre, ihre __order... Spalten gleich durch INSERT- bzw. UPDATE-Triggers zu pflegen, damit die Probleme gar nicht erst vorkommen.

Ich halte die Umstellung auf PGDBE für alles andere als einen Fehler. Aber diese Einschätzung hängt natürlich auch von der jeweiligen Situation ab. Aus meiner Sicht: Obwohl noch nicht alle Probleme beseitigt sind, ist das die beste technologische Entwicklung, die Alaska seit der Jahrtausendwende vorgestellt hat (sinngemäßes Zitat von David, wenn ich mich richtig erinnere).

Und ich würde einem Fremdsystem niemals Schreibzugriffe auf eine Datenbank einräumen, die unter meiner Hoheit steht und für die meine Anwendung die Verantwortung trägt. Ich würde eine API zur Verfügung stellen, oder Schnittstellen bauen oder Synchronisationstabellen verwalten, was weiß ich. Aber es geht nicht nur um Integrität und Stabilität. Bei uns hängen an den Daten sehr viele Prozesse, die sich nicht auf ein paar Trigger oder Stored Procs reduzieren lassen, und es geht um Dokumentationssicherheit und vieles mehr. Wenn ich das zum Herumstochern freigebe, kann ich es gleich in die Tonne klopfen.
Aber auch das ist natürlich individuell. Man sollte das differenzieren. Und nicht „Das ist scheiße, weil es für mich nicht funktioniert!“ rufen, sondern, wenn überhaupt, „Das ist für mich scheiße, weil es für mich nicht funktioniert!“

Richtig Tom.
Ich habe auch nicht den Einzig Wahren Weg.
Bei uns handelt es sich um eine firmeninterne Anwendung.
Xbase++ Programmierer sind nicht so leicht zu finden auf dem Arbeitsmarkt, und ich bin der einzige in unserer Firma.
Wenn ich nächstes Jahr in Rente gehe, wäre es gut wenn, unter strenger Aufsicht, andere Sprachen zusätzlich eingesetzt werden könnten.
Jemand muss bestimmt trotzdem Xbase++ lernen, die Hauptanwendung wäre vermutlich nicht innerhalb von 10 Jahren zu ersetzen.
Aber ich kann durchaus verstehen, dass mein Chef ein paar Optionen offen lassen will.

Außerdem habe ich als Quasi-Datenbankadministrator (für den Beruf bin ich nicht wirklich qualifiziert, bin aber der Einäugige unter den Blinden) schon mehrmals Xbase++ Code schreiben müssen für Datenkorrektur- bzw. Import-Aufgaben, die ich sonst viel schneller und effektiver direkt in SQL (über pgadmin4) hätte machen können.

Tom hat geschrieben: ↑Di, 28. Feb 2023 16:24 Aber auch das ist natürlich individuell. Man sollte das differenzieren. Und nicht „Das ist scheiße, weil es für mich nicht funktioniert!“ rufen, sondern, wenn überhaupt, „Das ist für mich scheiße, weil es für mich nicht funktioniert!“

Servus Tom und Frank,

da ihr mich damit meint möchte ich klarstellen, dass es nicht meine Absicht war den Eindruck zu erwecken, dass es "scheiße" ist. Das hab ich weder geschrieben noch damit gemeint. Ich hab beschrieben, welche Probleme bei mir durch "externe" Schreibzugriffe - was mir vorher nicht mal klar war, dass das als extern gilt, weil ich ja mittels Xbase++ und der PGDBE darauf zugreife - entstanden sind.

Falls das anders rübergekommen ist: Sorry.