Alaskas neues Lizenzmodell für die PGDBE - ab dem 1.7.2023

[sammler0002]

Philipp,

das alles gilt für Dich nur, wenn Du die PGDBE nutzen willst (also die sanfte Migration von dbf nach SQL mit Nutzung der Db...-Funktionen). Willst Du direkt mit SQL auf PostgreSQL zugreifen, betrifft Dich das nicht.

Jan

Danke Jan, so hatte ich es auch verstanden. Und das war bei uns auch die Überlegung. Denn eine Umstellung von 0 auf 100 mit allen Programmen ist für uns eigentlich kaum bis nicht möglich.

Der einzige Weg, den ich bisher sehe, ist eben sanft zu migrieren.

[brandelh]

Willst Du direkt mit SQL auf PostgreSQL zugreifen, betrifft Dich das nicht.

Wie meinst Du das?

Eindeutig, wenn man die PGDBE eben NICHT einsetzt, sondern die API Lösungen ...

[AUGE_OHR]

hi,

die "Nörgler" habe ALLE irgendwann mal Xbase++ erworben aber das ist Alaska nicht genug
Alaska will auch das der User JEDES Jahr eine Subscription "Kauft" um damit die "Entwicklung" zu finanzieren

mittels der Subscriptionen wurde PGDBE und Co entwickelt und was bekommt der User : die Rechnung

ich halte es für Vertrag-Bruch und fordere den Verein auf es Rechtlich prüfen zu lassen

[Martin Altmann]

Jimmy,
der Verein ist kein Vertragspartner von Alaska.

Viele Grüße
Martin

[Werner_Bayern]

Eindeutig, wenn man die PGDBE eben NICHT einsetzt, sondern die API Lösungen ...

Dann braucht man aber wieder ein Fremdprodukt!

[Werner_Bayern]

Aber. Drittes Jahrtausend hin oder her - wir kennen die Größenverhältnisse und wissen um sie. Und auch wenn so manches Jahr ohne direkt erkennbaren Gegenwert der Subskriptionsgebühren blieb, ist doch einiges passiert.

Servus Tom,

schön, dass wir uns fast einig sind

Ja, es ist einiges passiert, das leugne ich nicht. Aber der Großteil ist Bug-Fix und längst überfällige Funktionalität nachziehen - wie z. B. der HTMLViewer2, weil der IE nicht mehr unterstützt wird und HTML4 (XbpHTMLWindow und XbpHTMLViewer) einfach steinalt ist. HTML4 ist 26 Jahre alt, HTML5 gibts bereits seit 9 Jahren...

Was hat das mit der Größe eines Unternehmens zu tun? Hat das nicht was mit Preis-Leistung zu tun?
Überspitzt: Für Dich ist es ok, für 3000,-- € bei einem 5-Personen-Unternehmen ein Pflege-Verwaltungs-Programm zu kaufen, obwohl Du für 2500,-- € bei einer großen Firma mit 50+ Programmierern auch eins haben könntest, bloß mit 10facher Funktionalität - wo so gut wie alles bereits mit drin ist, was Du je benötigst?

Da würde ich eher erwarten, dass mir das 5-Personen-Unternehmen, das ja eine ganz andere Kostenstruktur hat, ein günstigeres Angebot macht als die großen und flexibel und schnell auf neue Technologien und Anforderungen reagiert. So kenne ich das. Anders haben die Kleinen doch kaum eine Marktchance?

Klar, dabei vergesse ich die Historie, in meinem fiktiven Fall - der hier ausdrücklich keine real existierende Firmen im Auge hat: Du hast bereits das Pflege-Verwaltungs-Programm bei der kleinen Firma gekauft und bist evtl. bis zu einem gewissen Maße daran gebunden...

Vielleicht sehe ich das auch alles völlig falsch

[brandelh]

Eindeutig, wenn man die PGDBE eben NICHT einsetzt, sondern die API Lösungen ...

Dann braucht man aber wieder ein Fremdprodukt!

du hattest gefragt wie JAN das gemeint hat, das ist die Antwort auf deine Frage

[Tom]

Hallo, Werner.

Für Dich ist es ok

Hätte ich vor zehn Jahren unsere Anwendung vollständig neu entwickelt, mit einer damals topaktuellen Entwicklungsumgebung, mit einer zukunftsträchtigen Technologie, mit einer großen Community und hunderttausenden Anwendungen weltweit, dann würden wir dieses Gespräch jetzt nicht führen; wir würden uns wahrscheinlich nicht einmal kennen. Aber ich habe vor 25 (!) Jahren vor der Entscheidung gestanden, entweder für zwei, drei Jahre komplett vom Markt zu gehen, um den damals schon 15 Jahre alten Code durch neuen zu ersetzen, oder auf dieses krasse Tool zuzugreifen, das es mir ermöglichen würde, diesen Code weiter zu nutzen und aufs nächste Level zu heben. Ich wusste damals schon, dass der Partner, der dieses Tool herstellte, nicht Microsoft, SAP oder Oracle war, sondern eine coole kleine Firma aus Frankfurt. Deren Hauptziel - eigentlich deren einziges Ziel - darin bestand, Leuten wie mir eine Lösung für die Situation anzubieten, und dieses Versprechen haben sie auch eingehalten. Es gibt uns immer noch, wir sind sehr gut reputiert, und wir nehmen regelmäßig unserem Hauptkonkurrenten Kunden weg, der zwanzig Mal so groß ist wie wir. Aber wir haben auch weitergelernt und uns mit anderen Technologien befasst; wir nutzen Zeug wie HTML 5 schon seit Jahren, wir haben mit Phonegap und Cordova und einigen Vorgängern geschafft und sind inzwischen bei React, und was auch immer wir uns wünschen, das lässt sich umsetzen. Nicht immer im Monolithen, aber das ist auch nicht nötig. Was wir aber auch immer noch mit uns herumschleppen, das ist das dateibasierte Datenbanksystem, entweder nativ oder mit der ollen Oma ADS als Babysitter, aus den gleichen Gründen wie damals: Wir müssten einen völlig neuen, vollständigen Branch aufmachen, um die Anwendung einerseits ständig den Anforderungen anzupassen und andererseits parallel datenbankmäßig zu migrieren. Aber auch hier hat Alaska ein Versprechen gemacht und weitgehend eingehalten. Es ist fast das gleiche Versprechen wie damals: Du kommst an aktuelle Technologie und an aktuelle Datenhaltungskonzepte, aber Du kannst Deinen Code einfach weiternutzen, jedenfalls zu Fensterkreuz mal Pi 98 Prozent.

Das Problem ist, dass die Basis für dieses Versprechen eine sehr viel kleinere als damals ist. In den Neunzigern gab es tausende von Clipper-Entwicklern, die nicht weiterwussten, und jetzt sind es vielleicht noch ein paar hundert, die ihre Xbase++-Anwendungen in die SQL-Welt migrieren müssen, um nicht vorzeitig vom Markt zu verschwinden. Ich verstehe, dass angesichts des großen Wertes, den dieser Ansatz für Leute haben kann, die eben nicht die Zeit und die Kapazitäten haben, mit anderen Tools und parallel und schrittweise Millionen Zeilen Code von ISAM nach SQL zu bringen, der Gedanke gereift ist, für diese abermalige Rettung auch eine entsprechende Vergütung abzurufen. Nein, "ok" ist das nicht, wenn es darum geht, wie und wann das kommuniziert wurde. Ich kann den Ärger darüber gut verstehen und nachvollziehen. Aber ich habe mindestens ebenso viel Verständnis dafür, dass ein Unternehmen, das auch ökonomische Aspekte zu berücksichtigen hat - nicht zuletzt im Hinblick auf die eigene Zukunft -, eine Einnahme zu realisieren versucht, wo die Investition wahrscheinlich ganz schön aus dem Ruder gelaufen (und noch nicht beendet) ist.

Wir haben in den vergangenen Jahren auch Preise angehoben, obwohl einige Verträge das nicht vorgesehen hatten, und darauf gehofft, die Kunden würden nicht ihr außerordentliches Kündigungsrecht nutzen, was sie tatsächlich in fast allen Fällen auch nicht getan haben, weil wir eine fantastische Leistung für dieses Geld erbringen und der Wechsel woanders hin noch viel, viel teurer gewesen wäre. Ich muss das, glaube ich, keinem hier erklären, warum man so etwas macht und wie die Abwägungen auf dem Weg zu solchen Entscheidungen aussehen. Das ist manchmal einfach alternativlos; langfristig wäre der Verlust für alle Beteiligten viel, viel größer.

Also. Das ist keine Frage von okay oder nicht okay, so einfach ist das nicht. Es ist auch keine Frage von Leistung und Gegenleistung.

[brandelh]

Ich habe Alaska zum ersten mal auf einer EDV Messe in München gesehen.
Clipper auf native OS/2 das fand ich cool, auch wenn damals nur wir Entwickler OS/2 hatten.
Mein damaliger Chef hat unterschrieben und seither waren wir Tester (OS/2 Pre-Release) ... dann kamen Windows (3.11) und keine OS/2 Rechner.

Mit Visual Objects fand ich für Windows (3.x) eine nette Umgebung und setzte damals ein neues Programm damit um ... vor der Veröffentlichung kam Win 95 und die Netzwerkprobleme damit.

Das Programm starb, meine Anwendungen blieben auf Clipper, Xbase++ für Windows nutzte ich zum experimentieren, dann kam auch Windows NT auf die Endgeräte, zum Schluss auf die Server mit Citrix und ich musste handeln.

In sehr kurzer Zeit habe ich die einen Anwendungen mit Hybrid Modus (Anwenderentscheidung) für das Jahr 2000 und Windows NT / Citrix Server tauglich gemacht und bei den anderen die GUI Umsetzung (gleiche Geschäftslogik) erledigt.

Später gab es Versuche mit Windev und mehreren Kollegen zusammen, aber aus verschiedenen Gründen kam es nie dazu.
Ich kam ja eigentlich von PowerBasic und habe auch noch diese Compiler, dennoch ist Xbase++ die Sprache die ich kann und bei der ich bleibe, wenn gleich ich auch wenig mit dem GUI Editor mache.

Alle meine produktiven Anwendung bei Endanwendern sind mittlerweile außer Dienst, ich nutze es nur noch für die eigenen Verwaltungsprogramme, die seit 20 Jahren ihren Dienst versehen, bis zu meiner Rente und dann war es das.

Ich freue mich sehr, damals Xbase++ kennengelernt zu haben, auch wenn die Clipper Konferenzen in Köln nie erreicht wurden

[AUGE_OHR]

hi Martin,

der Verein ist kein Vertragspartner von Alaska.

es geht nicht darum ob eine Geschäftliche Verbindung besteht sondern um das Interesse von User was doch der Zweck des Vereins ist
man hat nachträglich eine Änderung der "Nutzungsrechte" vorgenommen und setzt jetzt die User unter Druck ...

und dann kommt der CEO an und "bepöbelt" User als "Nörgler" weil die User sich dagegen wehren
dabei haben viel User mit Ihrer Subscriptiopn die Entwicklung von PGDBE erste ermöglicht

---

es geht NICHT um einen (Recht)-"Streit" mit Alaska, sondern Alaska zu "verwarnen" dafür das man User "bepöbelt"
es ist doch wohl klar das sich einige User, welche sich damit beschäftigt haben, nun echt sauer sind wenn die "Nutzungsrechte" nicht mehr "unbeschränkt" sind

HIER ist das Forum der User und da "beschwert" man sich schon mal wenn der "Hersteller" was macht was einem "ungerecht" erscheint

---

der Vorstand sollte auch bedenken "wie" die dar stehen wenn man Alaska das durchgehen lässt

man "lacht" jetzt schon über Alaska und den CEO wie er öffentlich User als "Nörgler" im Forum bezeichnet um sich zu "rechtfertigen"

klar fällt das auch auf die User des Forum und den Verein zurück die so was zulassen

[Jan]

Ach Jimmy,

was stellst Du Dir eigentlich vor? Das der Verein jetzt eine offizielle Petition bei Alaska einreicht? Und das die dann auch noch etwas bringt? Wie willst Du denn Alaska bitte schön verwarnen? Mit dem Zeigefinger wedeln und sagen "Du, Du, Du! Bist ganz böse, sei bitte brav!"? In welcher Scheinwelt lebst Du eigentlich?

Und Steffen hat hier niemanden als Nörgler bepöbelt. Er hat darauf hingewiesen das hier Mitschreiber gegen die neue Lizenzpolitik argumentieren, die die PGDBE gar nicht nutzen. Ich stimme da nicht mit ihm überein, auch wenn ich die nicht nutze darf ich als Lizenznehmer des Gesamtpaketes selbstverständlich eine Meinung dazu haben. Und die natürlich auch kund tun. Aber gepöbelt hat Steffen nicht. Man hört nur seinen persönlichen Unmut aus den Worten heraus.

Wer lacht denn über Alaska und den CEO? Ich habe davon noch nie gehört? Vielleicht in Deinem Kämmerlein mit Deinen harbour- oder sonstwas-Mitstreitern, wenn Ihr darüber ablästert. Aber sonst?

Jan

[Tom]

Das mit den Nörglern war ich, ich bin nur zitiert worden.

Und, Jimmy, wann hast Du zuletzt Subskritionsgebühren bezahlt? Oder mit der PGDBE gearbeitet?

[CRT]

Hallo zusammen,

also ich persönlich lehne dieses neue Lizenzmodell ab. Meine Kunden nutzen meine Zeiterfassung auf beliebig vielen Client's um sich an- oder abzumelden. Ich hatte meinen Kunden die vor vielen Jahren versprochene Möglichkeit des Einsatzes von PostgreSQL ebenfalls in gutem Glauben weiter versprochen, konnte aber aufgrund der Fehler in der PQDBE nie ausliefern. Das hat zum Verlust vieler Kunden geführt.

Nun wo sich abzeichnet, dass man das Ding endlich produktiv einsetzen könnte, wird es kostenpflichtig. Würden meine Lösung typischer Weise nur wenige Client's benötigen wären die 29,- EUR/Jahr/Client kein Problem, der Lizenzierungsaufwand jedoch schon. Es verkompliziert die Vertrags- und Produktgestaltung und stellt mich im Wettbewerb noch schlechter. Ich war einfach zu gutgläubig. Es wäre sinnvoller gewesen schon vor langer Zeit auf ein anderes Entwicklungswerkzeug zu setzen. Ich kann Jan nur voll zustimmen (ausgenommen der oft harschen Kritik an Jimmy's Meinung. Darf jemand der keine Subskription hat den keine Meinung haben oder auf bessere Lösungen in anderen Umgebungen hinweisen? Wieso dürfte der Verein die Meinung seiner Mitglieder nicht an Alaska kundtun?). Und das Alaska kein großer Hersteller ist, wir wohl auch am Gebotenen liegen. Viele Irrwege, Versprechungen, technologisch immer zu spät oder gar nicht und zudem viel zu teuer.

P.S. Falls jemand meine Zeitwirtschaftslösung kaufen möchte, samt Quellcode und möglichem Consulting für drei Jahre, einfach melden. Läuft Datei-basiert und mit dem ADS, beherrscht Anforderungen aus D-A-CH, I, SLO und ist in drei Sprachen (leicht erweiterbar) verfügbar.

lg
CRT

[brandelh]

hi Martin,

der Verein ist kein Vertragspartner von Alaska.

es geht nicht darum ob eine Geschäftliche Verbindung besteht sondern um das Interesse von User was doch der Zweck des Vereins ist

soweit ich mich erinnere ist der Zweck des Vereins, den Betrieb dieses Forums sicher zu stellen.

Sollte in der Satzung stehen.

[Herbert]

Ich freue mich sehr, damals Xbase++ kennengelernt zu haben, auch wenn die Clipper Konferenzen in Köln nie erreicht wurden

D'accord, genau meine Meinung. Aber auch ein paar Entwicklerkonferenzen mit euch Cracks waren sehr unterhaltsam und interessant.

Ich lese Frust und Unverständnis, stelle einmal mehr fest, dass mein Wechsel zu Windev sich mehr als nur gelohnt hat. (Ich darf das hoffentlich schreiben, da kein Hersteller in den Satzungen zu finden ist?)

Liebe Grüsse und entscheidet richtig, hoffentlich mit Zustimung von Steffen.

[AUGE_OHR]

hii Tom,

wann hast Du zuletzt Subskritionsgebühren bezahlt?

das geht dich gar nichts an "ob" oder "wann" ich Alaska mal unterstützt habe.

---

es gab eine Zeit da war Alaska das "beste" was es gab um von DOS nach GUI zu kommen
das OOP Konzept ist immer noch GUT ... aber 10 Jahre alt wo sich nichts getan hat

Oder mit der PGDBE gearbeitet?

als Alaska in Langenhagen 2012 PGDBE raus gebracht hat waren einige Leute dabei sich das Konzept "genau" anzusehen
dabei ging es weniger um die Performance als viel mehr um die Beschränkungen des "gemeinsamen" Zugriff von "anderen" Apps
hinzu kam der "Overhead" durch die ISAM Emulation von PGDBE sowie die Geschwindigkeit der weiter Entwicklung

ich habe mich also sehr intensive mit dem Konzept PGDBE befasst aber auch mit anderen Möglichkeiten
da ich nicht jahrelang auf PGDBE "warten" wollte habe ich mit Ot4xb das ganze "Native" gemachen

seit 2013 laufen damit die PostgreSQL Apps, inzwischen mit Version 14

---

die "Native" Version hat nun der Vorteil das die "portable" ist

ich habe damit inzwischen unter HMG / harbour auch eine 64 Bit Version
bei Fivewin arbeite ich an der "Import"-LIB für MSVC

der CLASS CODE kann zu 99% übernommen werden da es keine GUI Elemente enthält

ich bin also sehr zufrieden mit meiner Entscheidung von 10 Jahren diesen Weg zu gehen und nicht auf Alaska zu "warten"
das Alaska nun für die PGDBE auch noch "zusätzliche" Lizenz Gebühren verlangt ...

[brandelh]

als Alaska in Langenhagen 2012 PGDBE raus gebracht hat waren einige Leute dabei sich das Konzept "genau" anzusehen
dabei ging es weniger um die Performance als viel mehr um die Beschränkungen des "gemeinsamen" Zugriff von "anderen" Apps
hinzu kam der "Overhead" durch die ISAM Emulation von PGDBE sowie die Geschwindigkeit der weiter Entwicklung

genau das ist einer der Gründe, der mich zu SQLExpress for Xbase++ gebracht hat.

1. Verfügbar und getrennt von Workareas - auch wenn andere diese bevorzugen und das der Alaska Weg ist.
2. Die Native API Ansätze fand ich sehr interessant und hätte mich da auch reingekniet,

aber leider ist es bei uns nicht möglich gewesen mal soeben wie früher einen SERVER ins Netz zu hängen.
Aus Sicherheitsgründen (DBF und Indexe waren nach der Serverumstellung damals nicht mehr sicher) hätte ich gerne auf SQL Server gesetzt.

Natürlich ist das meine Subjektive Meinung, ich hab nur meinen Kopf zum denken, die anderen müssen Ihren selbst benutzen

Der Vorteil der DBF Speicherung war bis zum Ende, dass ich nur ein Laufwerk mit Schreibrechten brauchte.
Ich hätte gerne auch nach 2010 noch darauf vertraut, dass diese DBF / NTX / CDX auch mit dem neuesten Netzprotokoll zurecht kommt, aber man kann nicht alles haben.

Die Netzprobleme nach Umstellung auf Windows Server 2012 (aus dem Gedächtnis, kann auch ein anderer sein), hat das Vertrauen in meine Anwendungen zerstört.

[Jan]

Jimmy,

mit der PGDBE kannst Du Dinge machen, die kannst Du mit nichts anderem machen. Ja, um den Preis das andere Programme nicht schreibend auf die PostgreSQL zugreifen dürfen. Aber was da das kleinere Übel ist muß jeder Entwickler mit seinem Kunden selber entscheiden.

Und der Weg über ot4xb ist ja nun auch nicht wirklich der beste, oder? Wenn Pablo da nicht mehr weiter entwickelt? Alaska hat zwar eine längere Weile gebraucht um auch aktuellere Versionen der PostgreSQL zu unterstützen. Aber jetzt machen die es, und das wird weiter entwickelt. Und es gibt andere Produkte, mit denen man darauf zugreifen kann, die ebenfalls weiter entwickelt werden. SQLExpress, PQclass. Um nur zwei zu nennen. Aber die bieten halt eine grundlegende Funktion der PGDBE nicht.

Jan

[Tom]

das geht dich gar nichts an "ob" oder "wann" ich Alaska mal unterstützt habe.

Mehr noch: Es interessiert mich eigentlich nicht einmal. Meine Anmerkungen waren rein rhetorisch. Alles, was ich wissen muss, weiß ich.

[ramses]

Hallo zusammen

ich habe den ursprünglichen Beitrag selbst gelöscht.

[Tom]

Im Preis den du erwähnst ist auch Perfomance-Verlust und höhere Last auf dem Server enthalten.

Der Performance-Verlust betrifft vor allem die Servicefunktionen, woran meines Wissens gearbeitet wird, und sehr große Datenmengen. Serverlast kann einem heutzutage weitgehend schnuppe sein, aber wir haben u.a. einen PostGres-Server, der auf einer echten Möhre läuft, die wir mit diesem Server nicht einmal entfernt auslasten.

Aber all das ist eine Rechnung, die jeder für sich selbst aufmachen muss. Ich hab's weiter oben geschrieben - ich hätte mehrere Jahre lang mindestens einen Parallelbranch laufen lassen müssen, und wer weiß, wie komplex es werden kann, umfangreiche Branches zu mergen, weiß auch, wie viel Arbeit nur das gemacht hätte, von der eigentlichen, inhaltlichen Arbeit ganz zu schweigen. Wir hätten das nicht überlebt, Punkt. Selbst die Migration der PGDBE ist bei umfangreichen Monolithen ein ziemlicher Schuh, obwohl man den meisten Code unangetastet lassen kann. Ich kann nur - in Mannjahren - schätzen, was eine Low-Level-Datenbankmigration an Aufwand gekostet hätte, eine Umstellung auf natives SQL, mit welchem Einzelkämpfer auch immer (Boris, Pablo usw.). Es wären mehrere Mannjahre gewesen, gegen die wir uns einfach entscheiden mussten. Und wir sind mit den vorläufigen Ergebnissen hochzufrieden. Abseits der Servicefunktionen ist die PGDBE hochperformant, sie ist inzwischen sehr verlässlich, und es ist absolut kein Vergleich zur ollen Oma ADS. Ich kann unsere Kunden vor die Auswahl stellen und unseren Support allmählich an die veränderten Bedingungen führen. Ich scheiße ganz persönlich mit großem Abstand auf die (lösbaren!) Schwierigkeiten, die man bekommt, wenn andere Anwendungen in den Daten schreiben sollen, weil wir das weder zulassen würden, noch dieses Problem überhaupt haben, weil wir alles selbst können und machen. Ich will damit aber nicht sagen, dass ich auf die Leute scheiße, die dieses Problem haben - es betrifft mich nur nicht, und ich halte es - ganz persönlich - für ein Randproblem, wenn man die meisten Anwendungsfälle betrachtet. Es betrifft mich übrigens auch nicht, dass Leute nach der Maxime arbeiten, möglichst viel selbst zu machen oder auf dem niedrigstmöglichen Level herumzupopeln oder sonstwas zu tun - sollen sie. Jeder darf auf die Weise glücklich werden, die ihm gefällt. Aber aus der Perspektive unserer Kapazitäten und der Verantwortung, die ich für unser Unternehmen trage, ist die PGDBE eine perfekte Wahl.

Es nervt mich allmählich, dass immer wieder die gleichen Stöckchen geworfen werden. Soll doch jeder machen, wie er will. Dass man anderen ständig einzureden versucht, dass ihr Weg der falsche wäre, weil man unbedingt Solidarität für den eigenen Weg braucht, ist ein Zeichen von ... ach, ich halte jetzt lieber die Klappe.

[Jan]

Carlo,

hast Du meinen Beitrag gelesen? Offensichtlich nicht. Denn ich schrieb über den Zugriff ohne SQL-Anweisungen. Den keine andere Schnittstelle bietet. Und ich habe auch ausdrücklich darauf hingewiesen das man selber entscheiden muß was für einen der bessere Weg ist.

Nicht jeder kann den Weg gegen sein Programm von DB-Funktionen auf SQL-Anweisungen einfach mal eben so umzuschreiben. Und für diejenigen mag dieser Modus genau der Weg zu sein, seine Applikation auf eine SQL-Datenbank aufzusetzen. Trotz der damit verbundenen Nachteile.

Die Entscheidung ist also: Nachteil Kompatibilitätsmodus gegen Nachteil alles umschrieben müssen. Dafür wird es keine allgemeingültige Antwort für jeden geben. Ich hatte da z. B. auf der letzten Konferenz "meinen" Weg vorgestellt. Der noch ein ganz anderer ist. Der aber ganz bestimmt nur für wenige Entwickler und Anwendungen gelten kann. Alles hat Vor- und Nachteile. Jeder muß die für sich abwägen und entscheiden.

Jan

Edit: Tom war mit seinem ganz praktischen und realen Beispiel schneller als ich mit Unterbrechungen getippt habe.

[ramses]

Hallo zusammen

ich habe den ursprünglichen Beitrag selbst gelöscht.

[Martin Altmann]

Kann man nicht einen Proxydienst aufsetzen? Nur dieser nutzt die Verbindung mit PGDBE zum Server. Pro Installation nur eine Lizenz.

Viele Grüße,
Martin

[Tom]

Der Administrative Aufwand mit den Lizenzen scheint mir jetzt einfach zu hoch

Ich dachte auch, der würde hoch sein, ist er aber nicht. Es hängt vom Modell ab. Ich würde Dir (und auch "CRT", bevor er seinen Code verscherbelt) einfach mal raten, direkt mit Alaska zu quatschen.