Zukunft von XBase++ ?

[ASA]

Hallo,

ich bin gerade dabei eine Analyse von der bestehenden Software in unserem Unternehmen zu machen.
Das ganze ist mal in dBase geschrieben worden.
Nun stellt sich hier die Frage ob man das ganze auf XBase konvertieren sollte.

Nun frag ich mich natürlich,
seit wann gibt es XBase, wie groß ist die XBase Gemeinde allgemein,
und wie wahrscheinlich ist es,
das Alaska Software in 5 Jahren noch existiert.


Liebe Grüße
Angie

[Rolf Ramacher]

Hi Angie,

ich denke mal das die Anwender von Xbase++ zugenommen hat. Sieht man an den hier angemeldeten Teilnehmern. Aber vielleicht kann dir Tom hierzu mehr erzählen. Aber wenn du von Clipper kommst, kannst du sehr viele Befehle weiter gebrauchen, da diese übernommen wurden. Andere wurden verändert / neue hinzugenommen.

[Martin Altmann]

Hallo Angie,
gute Frage, auf die es in der heutigen, schnellebigen Zeit latürnich keine Antwort gibt!
Wer weiß schon, ob es eine Firma mit einem relativen Nischenprodukt in 5 Jahren noch gibt. Bisher gibt es Xbase++ für Windows seit über 10 Jahren - schon nicht schlecht, wenn man bedenkt, wie lange Clipper unter dem letzten Rechteinhaber noch gelebt hat
Ich persönlich bin relativ zuversichtlich - aber das wird Dir sicherlich auch nicht in Deiner Entscheidungsfindung helfen

Viele Grüße und viel Spaß hier im Forum,
Martin

[brandelh]

Hi,

zu dem Thema wurde hier schon viel diskutiert, wie bei anderen Sprachen auch

Bei der Software muss man sich immer entscheiden zwischen einfacher Umsetzung (Xbase++ SUPER, aber wenig/keine GUI)
und neu schreiben mit allen Mitteln die ein modernes OS mit moderner Software zur Verfügung stellt.
Wer die IDE von Visual Basic mit den Paintern kennt und nicht missen möchte, sieht mit Xbase++ (zur Zeit) kein Land.
Mit Zusatztools oder Handarbeit (die ich bevorzuge) geht sehr viel mit Xbase++.

Ob Alaska-Software in 5 Jahren noch lebt ?
Wer weiß das schon, aber wer hätte gedacht dass Borland Delphi verkauft und M$ ohne Not Visual Foxpro sterben lässt.
Alaska-Software hat nur Xbase++ als Produkt !

Mit der aktuellen 1.90.331 ff könnte ich gut leben, auch wenn Alaska-Software unter ginge, aber
nach dem was man hört und ab und an sieht, sind die schwer am Arbeiten um Xbase++ im Datenbereich
deutlich vorwärts zu bringen (native SQL, das wär schon was ).

Vielleicht gibt es dann auch mal Visuelle Painter

Was die Benutzerzahlen angeht, die verrät niemand aber ich denke schon, dass es in D mehr gibt als sich hier angemeldet haben ...

[Manfred]

Hi,

hier auch mein Senf....

Ich habe vor ein paar Tagen mal im Internet nach xbase++ gesucht. Es kommen doch etliche zusammen, die damit arbeiten und von denen ich meine, dass sie nicht hier im Forum vertreten sind. Aber wie sagt man so schön: Nicht die Menge macht es.
Ansonsten dürftest Du wohl hier viel Hilfe bekommen, wenn Du sie denn brauchen würdest. Oder aber, Du trittst einer der XUG´s bei. Dort findet man sicherlich auch viel Hilfe.

[Jan]

Zu den Userzahlen: Steffen hat neulichst erzählt, das es Unmengen von User gibt, die niemals posten, sondern "nur" lesen. Die ein Vielfaches der gemeldeten user ausmachen. Das kann er natürlich nur für die Alaska-NG sagen. Aber ich denke, daß es für das Forum ähnlich gilt. Wenn ich sehe, wie häufig hier nicht angemeldete Gäste lesend unterwegs sind, dann gibt das schon zu denken.

Abgesehen davon: Wenn ich mir die Pläne von Alaska ansehe, was die alles noch in der Planung haben, und das die ebenfalls planen, zum Ende des Jahres ihr Personal aufzustocken, dann bin ich für die kommende Jahre zuversichtlich. Sowohl was den Bestand der Firma Alaska angeht als auch was die Aktualität der Software Xbase++ angeht.

Jan

[Tom]

Clipper bzw. Nantucket "gibt" es schon seit mehr als einem Jahrzehnt nicht mehr, aber die Applikationen laufen immer noch, sogar unter Windows 7. Wer Zukunftsängste in dieser Hinsicht hat, sollte sich fragen, worin genau die bestehen. Solange Microsoft die Kerne der Betriebssysteme nicht so ändert, dass alter Code überhaupt nicht mehr funktioniert, kann man sogar bei einem längst abgekündigten Compiler noch davon ausgehen, dass Produktivarbeit damit über Jahre hinaus möglich ist.

Zukunftssicherheit gibt es nie. Selbst eine gutgehende Firma kann (Einverständnis und Gewinnstreben der bisherigen Eigentümer vorausgesetzt) aufgekauft und dichtgemacht werden, weil sie vorher eine unliebsame Konkurrenz dargestellt hat. So etwas geschieht ständig, auch bei mittelständischen Softwarehäusern. Und natürlich suggeriert Microsoft gerne, dass man nur auf der sicheren Seite wäre, wenn man deren Produkte nutzt, aber inwieweit das .NET-Framework wirklich das vorläufige Ende der Fahnenstange darstellt oder mittelfristig dem gleichen Schicksal anheimfällt wie VF, weiß derzeit keiner. Bei Xbase++ können wir immerhin sicher sein, dass es nicht kurzfristig gegen ein Ybase-- ausgetauscht wird und alter Code in die Tonne geklopft werden muss.

Man kann an Xbase++/Alaska Software viel kritisieren, und ein Teil dieser Kritik ist sicherlich berechtigt (z.B. diejenige, die die Einhaltung von Terminen anbetrifft). Es gibt aber eine solide, sehr umtriebige Community, es gibt kurze Wege zwischen Compilerhersteller und Entwicklern, und es gibt fast nichts, das mit der Sprache unmöglich wäre. Einiges ist hakeliger und umständlicher als z.B. mit VB oder C+/++, dafür sind andere Dinge leichter und eleganter. Und was wirklich nicht geht, das löst man über Fremdbibliotheken und eingekaufte Komponenten. Das machen die Entwickler, die mit anderen Compilern arbeiten, aber auch so.

In der allergrößten Not gäbe es übrigens auch noch andere XBase-Compiler, die mit XBase++-Code ziemlich kompatibel sind. Nicht alle davon sind brauchbar, verlässlich oder bereits in Produktivumgebungen einsetzbar, aber es ist eben nicht so, dass es absolut keine Alternativen gäbe - für den Fall, den wir uns alle nicht wünschen, die Kollegen in Eschborn eingeschlossen.

[Jan]

Einige Beiträge oben treiben mich dazu, noch ein wenig mehr von meiner Meinung dazuzugeben.

Er meint, es gäbe ja auch noch andere Wettbewerber auf dem xBase-Markt. Wenn ich mir aber z. B. die Kommentare von Herbert ansehe, der vor Xbase++ mit einem solchen Produkt gearbeitet hat, dann ist zumindest der umtriebigste auf dem Markt bei weitem noch nicht so weit, wirklich markt- oder konkurrenzfähig zu sein. Sicher ist es beruhigend zu wissen, daß die Sprache ansich bei weitem nicht tot ist sondern eine gute Zukunft hat. Aber zumindest im Moment gibt es zu Xbase++ anscheinend keinen ernstzunehmenden Konkurrenten.

Hubert liebt seine Basic-Pointer. Ich selber kann damit garnichts anfangen, vermisse sie also nicht. Was ich dagegen liebe ist, mit nur 1 Zeile Code einen absolut stabilen Thread aufzumachen, bei dem ich mir keinerlei Sorgen um Datenkonsistenz machen muß. Einfach mal eben eine Auswertung nebenher laufen lassen und an meinen anderen Daten gleichzeit weiterarbeiten, oder die gleiche Datenbank mehrfach öffnen - null problemo. Und solche Gimmicks gibt es überall in Xbase++, die einem die Arbeit leicht machen. Sicher, maches ist aufwändiger als in anderen Sprachen. Aber maches eben auch einfacher.

Jan

[Alfred]

Hallo Angie,

ich habe mich bei meinem Umstieg von Alaska auf Delphi von folgendem leiten lassen:

- deckt mein neues System die nächste Betriebssystemgeneration von MS noch ab?
- gibt es ein komfortables Datagrid
- kann ich meinen Reportgenerator(Fastreport) weiter verwenden
- nativer Zugriff auf eine SQL-Datenbank(hier: Firebird)
- Kosten
- wie gut ist der Support durch den Hersteller des Compilers und die Anbieter von Zusatztools.
- der ist z.T. sehr gut(DevExpress, TMS).

Was ich sehr schnell aufgeben habe ist eine bestehende, über Jahre gepflegte Software(Basis
FoxPro 2.6) auf das neue System umzustellen. Solange die Anwendung seine Funktion erfüllt,
muss man sich einfach die Frage stellen, ob die neue Optik den Aufwand wirklich wert ist?

In Bezug auf dbase möchte ich dir empfehlen einmal den ADS anzuschauen. Der ermöglicht
es die alte und neue Welt parallel zu bearbeiten. Zum Test kann man den localen Server
verwenden, der ist kostenlos(aber keine Multiuserzugriff). Im professionellen Einsatz kostet
der Server jedoch richtig Geld. Das Produkt wurde extra für die alten dbfs entwickelt. Ge-
testet habe ich es auf einem Samba-Server(Fedora 10).

Am meisten vermisse ich in der neuen Welt ein Forum wie dieses.

Gruß
Alfred

[Tom]

Hallo, Jan.

Ich habe mich missverständlich ausgedrückt. Derzeit scheint es keine nutzbaren Alternativen zu Xbase++ zu geben, wenn man robuste und auslieferungsfähige Xbase-GUI-Anwendungen entwickeln will. Aus unserer Sicht sind ja auch keine erforderlich. Aber es gibt Projekte, an denen gearbeitet wird. Was bedeutet, dass man aller Voraussicht nach nicht mit nutzlosem Quellcode dastünde, käme es zum absolut unerwünschten GAU.

[brandelh]

Hubert liebt seine Basic-Pointer.

aber JAN, etwas genauer solltest du schon lesen
Ich schrieb "Wer die IDE von Visual Basic mit den Paintern kennt und nicht missen möchte... "
Also weder ICH noch POINTER

Die IDE von Visual Basic habe ich nie vermisst, auch PowerBasics IDE kann da nicht mithalten, aber der PB-Compiler erzeugt sehr schnelle, sehr kleine eigenständige EXE Dateien und das liebe ich - für einfachere Sachen ... ich bin schließlich kein BASIC Experte
An Xbase++ liebe ich das Klassenmodell, das man so schön anpassen kann.
Was nützen mir die schönsten controls wenn sie nicht machen was ich will - mit Xbase++ habe ich meist das Verhalten hinbekommen das ich wollte ... ab und an mit Hilfe von anderen, aber für was gibt es denn ein Forum

PS:

früher liebte ich die DBF/NTX Dateien, aber bei größeren Installationen sollen die nicht sauber arbeiten,
was solls, es gibt heute ja SQL Server und mit SQLExpress kann man damit sofort sauber arbeiten.
Wenn erst die native SQL Unterstützung in Xbase++ enthalten ist, dann geht die Post ab.
Wobei - ich muss es einfach sagen - für kleinere Benutzergruppen sind die DBF/NTX eine gute Wahl.
Keine Installation eines Server, keine neuen Programme nötig ...

[AUGE_OHR]

PS:
früher liebte ich die DBF/NTX Dateien, aber bei größeren Installationen sollen die nicht sauber arbeiten,
was solls, es gibt heute ja SQL Server und mit SQLExpress kann man damit sofort sauber arbeiten.
Wenn erst die native SQL Unterstützung in Xbase++ enthalten ist, dann geht die Post ab.
Wobei - ich muss es einfach sagen - für kleinere Benutzergruppen sind die DBF/NTX eine gute Wahl.

ein Grund warum ich DBF benutze ist doch das meine Applicationen Datensatz orientiert ist und deshalb dort "schneller" als jede SQL Engine ein Ergebniss liefert.
Erst bei einer Datenmenge geht bei SQL die Post ab den "SET FILTER" ist bekanntlich sehr langsam ...

Nun habe ich aber "praktisch" kaum eine Application wo ich eine Menge suche sondern eigentlich
immer "einen exakten" Datensatz (Kunde, Artikel, Rechnung) und da ist Xbase++ immer noch
schneller als SQL.
Auch mit SCOPE und DBEVAL() ist man bei kleinen Mengen ziemlich schnell obwohl ja jeder
Datensatz "angefasst" wird.

Erst wenn ich z.b.alle Positionen einer Rechnung haben will dann wird es eine Menge wie
beim Browse ... und da haben wir noch den "Skipper" ...

klar könnte man auch DacPagedDataStore() nehmen und wäre dann wohl bei SQL Äquivalent
wobei ich nicht weiss wie :scrollDown(), :scrollUp() oder :scrollTo() intern arbeiten ( relative Position ?)

Wie das wohl bei Artica wird ? Eine "Umstellung" von Datensatz auf Datenmenge ... da müsste
auch die "Logik" angepasst werden ... nix mehr mit SKIP +1 und kein eigener "Skipper" wie beim
DacPagedDataStore() ... hm

[brandelh]

Hallo Jimmy,

vor kurzem ist mir ein übler Fehler passiert, ich habe eine Druck-Funktion wiederverwendet,
die vorher die Datei geöffnet und geschlossen hat. Nun brauchte ich das Gleiche nochmals
in einem anderen Zusammenhang. Dort war die Datei offen, also einen weiteren Paramter (IsFileOpen)
übergeben und die Funktion angepasst ... aber leider übersehen, dass die aufrufende Funktion
den Index mit setOrder() anders benötigt hat als die eingefügte und vergessen die order wieder
zurückzusetzen. Bei meinem Testdaten ging noch alles gut (Zufall) aber beim Produktionsbetrieb
"fand" die Routine nach dem Einschub nichts mehr und so vergingen Monate bis bemerkt wurde,
dass die gedruckten Sätze nicht abgeschlossen wurden ... mit SQL wäre das nicht passiert

Das eine DBF bei einem Datensatz schneller ist als ein SQL Server kann ich übrigens nicht glauben !
Wenn die DBF klein ist ohne Index müssen beide voll einlesen - der SQL Server bestimmt nicht langsamer (cache)
Wenn die Datendateien groß sind, dann muss man einfach bei beiden Systemen die Indexe richtig setzen.
Und auf dem SQL Server sind die viel einfacher, da die ORDER BY Klausel das Ergebnis nachsortiert,
dafür habe ich in DBF NTX Systemen oft einige zusätzliche Indexe benötigt.

Aber ich gebe dir Recht, dass DBF im Moment noch einfacher ist

[AUGE_OHR]

Das eine DBF bei einem Datensatz schneller ist als ein SQL Server kann ich übrigens nicht glauben !

die Betonung liegt auf "einem Datensatz", also ein SEEK().
Das wurde übrigens auf dem Usertreffen Röstal im Vortrag mitgeteilt.

[ASA]

Hallo @all,

ich danke euch allen für eure Meinung bzw Erfahrungsberichte.
Es war sehr hilfreich, eure Meinungen zu lesen.