Xbase++ 2.0 CTP3 Build 2.0.441

[UliTs]

Hallo Allerseits,

hat jemand von Euch schön mit obiger Version übersetzte Anwendungen beim Kunden laufen?

- Setzt jemand dabei "Universal SQL-Unterstützung" in Verbindung mit dem "Advantage Database Server" ein?
- Auch DataObjects?

Hat sich schon jemand das "neue Datenmodell für die Xbase++-Beispielsammlung" in Verbindung mit "Advantage Database Server Dictionaries" angeschaut?

Laut Alaska-Homepage soll das ja alles gehen .

Uli

[Wolfgang Ciriack]

hat jemand von Euch schön mit obiger Version übersetzte Anwendungen beim Kunden laufen?

Das wäre ja ganz schön fahrlässig !

[georg]

Hallo,


das kommt immer auf den Kunden und den Hintergrund eines solchen, beidseitig vereinbarten Tests an.

[UliTs]

Das wäre ja ganz schön fahrlässig !

Traust Du Alaska so wenig zu?
Schließlich haben sie die Version laut Homepage freigegeben! Da steht zum Beispiel nichts von einer Test- oder unfertigen Version .

Uli

[Martin Altmann]

Uli,
sorry - aber das macht doch schon die Bezeichnung klar: Preview

Viele Grüße,
Martin

[Tom]

Ich käme im Traum nicht auf die Idee, mit "Technology Previews" hergestellte Software an Kunden auszuliefern, auch nicht an solche, denen man verdeutlicht hat, dass es sich um "Beta" im weitesten Sinn handelt. Das tun wir frühestens, wenn die erste "richtige" Fassung der 2.0 vorliegt. Aber wir haben von einem guten Dutzend Kunden mit verschiedenen Betriebsgrößen Echtdaten, die bei uns in verschiedenen Topologien laufen. Mit derlei würden wir testen. Aber auch nicht mit einem Preview. Ich fasse die 2.0 frühestens im Stadium "Release Candidate" an.

[Rudolf]

Hallo,
ich kann auch nur eindringlich davor warnen. Ich habe damals die ODBCDBE vorschnell eingesetzt als sie rausgekommen ist, hat mich sehr viel Zeit und Geld gekostet, musste dann alles nochmal auf SQLEXPRESS umschreiben. War ein langer Kampf mit Alaska bis die alle Fehler als PDRs akzeptiert haben, und die Korrekturen kamen dann irgendwann viel später mal. Bei Boris wurden die wenigen kleinen Fehler sofort korrigiert, und das ohne lange Diskussion.
Ich werde auf alle Fälle mindestens ein Jahr warten nachdem die neue Version offiziell raus ist bevor ich ein Projekt umstelle und offiziell ankündige.
Grüße
Rudolf

[UliTs]

Uli,
sorry - aber das macht doch schon die Bezeichnung klar: Preview

Martin,
ja, du hast Recht: Preview = Vorschau = Programmvorschau ...
Wäre ja auch zu schön gewesen ...

Da die Version kostenpflichtig ist, war ich nicht drauf gekommen, dass sich Alaska das Testen Dritter bezahlen lassen will.

Ich habe auf die Schnelle auf der Alaska keinen Termin gefunden, zu dem zur Zeit xBase++ 2.0 rauskommen soll.
Übersehe ich da etwas?

Uli

[Manfred]

Nein, Du übersiehst nichts. Und selbst wenn, es wäre eh egal. Termine sind Schall und Rauch.

Und das Bezahlen für Testen....

Nun, da gab es schonmal abenteuerliche Erklärungen für.....

[AUGE_OHR]

hi,

witzig finde ich das man argumentiert das die CTP3 ja noch nicht das endgültige Produkt sei ... wann ist es denn "fertig" ?

und auch wenn man ein "fertiges" Produkt hätte muss man erst mal lernen mit den neuen Sachen umzugehen
und das konnte man schon mit der Hannover Devcon Build.

ich verwende den Xbase++ v2.x Teil und PostgreSQL welches bei paar Kunden als "Test" Versionen laufen.
es geht dabei um SQL was ein anderes Konzept als mit DBF erfordert und das müssen "wir" uns erarbeiten.

wer also "denkt" mittels pgDBE kann man PostgreSQL Client Applikationen "einfach so" schreiben
der wird ganz schnell merken das es ohne PostgreSQL Kenntnisse nicht gehen wird.
dito mit dem CXP Kram wer da nicht HTML, Java etc. "beherrscht" wird da als Newbie untergehen.

wer es also "heute" nicht "testet" muss das ganze dann eben mit dem "fertigen" Produkt machen
nur dann kann man keinen "Einfluss" mehr darauf nehmen ... das geht nur in der "Test" Phase.

deshalb bin ich erstaunt das so wenige die CTP "testen" und noch mehr das keine Kommentare kommen.
scheinbar haben die meisten wohl keine Meinung dazu "was" Alaska uns da gibt womit wir arbeiten sollen.


***

da ich individuelle Programme für die Kunden entwickle "spreche" ich mich mit den Kunden ab.
die "Test" Versionen sind also zum "abstimmen" mit dem Kunden "wie" wir das Thema SQL angehen wollen
wobei es nicht um die "Technik" sondern um das User Interface geht womit der Kunde arbeiten soll.

ein "Power" User, der schon länger mit eine Applikation arbeitet, benötigt viele "Hilfen" nicht.
er hat beim arbeiten einen (schnellen) Rhythmus den man nicht verändern darf da diese User meistens "blind" arbeiten.
genau da liegt aber das Problem mit SQL wo man teilweise einem anderen Konzept folgen muss.

***

wenn ihr meint euer Source Code sei so gut das er auch mit Xbase++ v2.x "ohne Probleme" läuft dem
kann ich nur sagen : Ihr werdet euch wundern "was" man ändern muss um "noch genauer" zu sein.

insbesondere die Presentation Space / Parameter in Zusammenhang mit Bitmap oder Font machen
schon mal "Probleme" was meistens am eigenen Source Code hängt weil v2.x es "noch genauer" nimmt.

[Wolfgang Ciriack]

Hallo Jimmy,

wobei es nicht um die "Technik" sondern um das User Interface geht womit der Kunde arbeiten soll

Also m.E. ist es dem Kunden vollkommen egal, ob hinter seinen Eingabemasken DBF, SQL, TXT oder sonst irgendetwas liegt.
Wichtig ist für Kunden die Funktionsfähigkeit und das User Interface, und das darf nicht von der dahinterliegenden Datenverwaltung abhängen. Ob die Daten für mein Browse von einem SQL-Server oder aus einer DBF-Datei kommen, ist egal, hauptsache sie kommen schnell

[AUGE_OHR]

hi,

Ich meine doch genau "das" was du da sagst das die User es nicht mögen wenn man ihren Rhythmus stört.
wenn nur dein Browse statt 1/10sec auf einmal 3-4Sec mit pgDBE braucht bis er "reagiert" wird das eben nicht gehen.
da muss man sich eben was einfallen lassen "wie" man den mit dem "neuen Werkzeug" umgeht den ein "normales" GOBOTTOM ist bei SQL "by Design" langsamer als ein GOTOP.

ich spreche selbstverständlich über "grosse" Datenmengen ... sonst könnte ich ja auch DBF nehmen.

[Tom]

Ich muss mich revidieren. Da unsere Haus-IT (Auftragsverwaltung, CRM usw.) auch aus unserer eigenen Produktion stammt, werden wir im Frühjahr diese Software auf die 2.0 umstellen und dieserart die ersten Tests durchführen.

[Rudolf]

Hallo,
das ist z.B. mein größtes Problem, da bei mir alles über Browser mit inkrementeller Suche geht. Das hat sich sehr bewährt bei meinen Kunden, das sie schon bei einer Teileingabe die verschiedenen Wahlmöglichkeiten sehen. Habe zwar mal Steffen bezüglich Browsergeschwindigkeit angeschrieben, er war der Meinung dass es kein Problem darstellen wird, aber das kann ich nicht glauben. Meine Kunden sind immer fasziniert wie schnell eine inkrementelle Suche mit fast einer Million Datensätze im Browser geht. Hier werden sicher die großen Geschwindigkeitsnachteile von SQL gegenüber DBF am besten ersichtlich.
Grüße
Rudolf

[UliTs]

...Hier werden sicher die großen Geschwindigkeitsnachteile von SQL gegenüber DBF am besten ersichtlich.

Wieso Nachteile?
Im Gegenteil: Vorteile!
Wenn die SQL-Implementierung gut ist, dann muß es in Verbindung mit Datenbankservern viel schneller werden!
Beim ADS (Advantage Database Server) kann man die hohe Geschwindigkeit sogar auf DBF-NTX oder DBF-CDX-Tabellen erreichen .

Uli

[Rudolf]

Hallo,
also wenn was langsamer wird, und komfortable Funktionen nicht mehr möglich sind, dann sehe ich das schon eher als Nachteil SQL hat für mich Vorteile bei komplexer Teilmengenwahl für den Browser. Bis jetzt habe ich das mit eXpress++ mit DC_SETSOPEARRAY und DC_SETSCOPE ganz gut hinbekommen. Das betrifft nur Geschwindigkeit, SQL hat natürlich viele andere Vorteile.
Grüße
Rudolf

[UliTs]

Man hat eigentlich immer eine Teilmengenauswahl beim Browser und sei es nur, dass man nicht alle Spalten der Tabelle darstellt .
Du kannst ja mal bei 100.000 Datensätzen einen Filter über ein MEMO-Feld setzen, bei dem nur wenige Datensätze herausgefiltert werden: da bricht ohne Datenbankserver alles zusammen, aber mit ...

Uli

[Rudolf]

Hallo Uli,
das stimmt natürlich, da nehme ich jetzt DC_SCOPEARRAY, aber es ist trotz normaler Navigation durch die Datesätze mit DBF auch noch erstaunlich schnell, kommt natürlich auf die Hardware und OS an. Derzeit kann ich es dem Kunden noch begreiflich machen dass er bei komplexen Abfragen ein wenig warten muss. Aber mit ADS wäre es sicher schneller und einfacher auf dieses System umzustellen.
Grüße
Rudolf

[AUGE_OHR]

das ist z.B. mein größtes Problem, da bei mir alles über Browser mit inkrementeller Suche geht.

das ist nur dann ein Problem wenn man ein "Standard" Browse benutzt

Tatsächlich kann man aber nur so viele Daten anzeigen wie auf den Bildschirm passen !
mehr Daten im Result Set, welche sich aus der Query ergibt, sind nicht notwendig also LIMIT verwenden !

und genau solchen Stellen wird man "überarbeiten" müssen um dann mit noch viel grösseren Datenmengen zu arbeiten.
sicherlich wird man mit pdDBE auf die "alte" Weise arbeiten können bei < 100.000 alles noch kein Problem mit 1-2Sec ...

wir als Xbase++ User sind viel zu "verwöhnt" mit einem XbpBrowse was es ja gar nicht als Windows Control gibt.
Deshalb liegt die Lösung auch ausserhalb von Xbase++ ... "wie" machen es die "anderen" Sprachen ?

[UliTs]

...
Tatsächlich kann man aber nur so viele Daten anzeigen wie auf den Bildschirm passen !
mehr Daten im Result Set, welche sich aus der Query ergibt, sind nicht notwendig also LIMIT verwenden !
..

Die Verwendung von LIMIT ist meistens nicht notwendig, so lange man mit Live-Cursorn arbeitet und weil die meisten SQL-Datenbankserver dermaßen schnell sind, dass es meist keine Rolle spielt.

Wenn man sich aber die Mühe macht und einen Browser schreibt, der selbstständig beim scrollen die benötigten LIMIT-SQL-Statements erzeugt, dann kann nun wirklich (fast) nichts mehr schiefgehen . "fast", weil man dadurch nicht mehr die Möglichkeit eines statischen Cursors hat, sondern zumindest eine "Mischung" aus statischem und Live-Cursor.

Uli

[brandelh]

Hi,

auch bei sehr großen DBF Tabellen (hauptsächlich wenn viele Felder enthalten sind) kann es ohne Filter zu Anzeigeverzögerunen kommen.
Das sind dann zwar nur eine oder zwei Sekunden, dennoch ist es "unschön".
Spätestens wenn ein Filter zunächst viele Zeilen überspringen muss, bevor er genug Zeilen für die Anzeige hat wird es sehr unschön und wenn man dann Blättert ist Feierabend.
Jede Sortierung ihrerseits benötigt dann noch einen eigenen Index und je mehr man davon hat, umso langsamer wird alles (insbesondere wenn man das Standardsperrverhalten nimmt).

Wenn es wirklich schnell angezeigt wird, dann nur deshalb weil die Tabelle wenige Felder hat und kein Filter eingesetzt wird.
Dann kann XbpBrowse() die Anzeige schnell aufbauen und auch die Navigation geht einigermaßen.
Die beschriebene inkrementelle Suche ist nur dann schnell, wenn man einen passenden Index hat und mit SetScope arbeiten kann.

Wenn diese Idealbedingungen nicht vorliegen kann man z.B. den Artikel von Alaska nutzen und eine Teilmenge anzeigen während ein eigener Thread die Folgezeilen weiter sucht.

Eine saubere SQL Implementierung macht nahezu alles besser, hier kann man die Treffermenge begrenzen (wer will schon mehr als die ersten 100 Treffer wirklich sehen ?) und
schon die Sortierung bei der Anfrage bestimmen. Insbesondere ist man nicht mehr von defekten Indexdateien betroffen, die ein riesen Problem darstellen sobald man die Idealbedingung verläßt. Gerade bei der Implementierung von Android Anwendungen habe ich SQL(ite) schätzen gelernt, im Netzwerk braucht man einen richtigen SQL-Server, aber MySQL / PostgreSQL sind schnell installiert und mit SQLexpress gut beherschbar.

[Rudolf]

Hallo,
laut damaliger Antwort von Steffen in der Newsgroup regelt das Xbase++ selbstf, so sollte es auch sein. Alle Browser selbst zu modifizieren ist im Nachhinein bei mir nicht möglich.
Grüße
Rudolf

[UliTs]

Alle Browser selbst zu modifizieren ist im Nachhinein bei mir nicht möglich.

Wenn Du nur eine Browser-Klasse hast, brauchst Du nur die zu erweitern/anzupassen .
Uli

[Rudolf]

Hallo,
leicht gesagt hab ich vor Jahren mit der ODBCBE probiert, war viel zu langsam für meine Zwecke, das sollte schon wie schon gesagt Alaska implementieren. Es macht keine Sinn wenn jeder selbst was basteln muss.
Grüße
Rudolf

[georg]

Hallo, Rudolf -

da will ich Dir mal widersprechen.

Aufgrund der langen Historie, die Xbase++ hinter sich hat (schliesslich steht es in der Nachfolge von dBase III oder so gar noch älter), ist Rückwärtskompatibilität wieder und wieder ein Thema.

Das hat sich auch in der PostgreSQL-Implementierung gezeigt (siehe die ganzen Beiträge von Jimmy).

Alaska wird bei der Implementierung immer wieder auf diese Dinge Rücksicht nehmen müssen, und damit auch Bremsen einbauen müssen.

Ich verweise - was SQL-Anbindung angeht - auch noch einmal auf Hector Peroza's Wrapper Klasse, mit der man MySQL- oder PostgreSQL-Datenbankem einfach, schnell und effizient einbinden kann. Man muss aber auch seinen Programmcode ändern, da gewisse Dinge (siehe auch meine Beiträge hier zum Thema SQL) anders gemacht werden müssen.

Wer auf Alaska und deren Implementierung wartet, der wird (immer und immer wieder) vom Leben enttäuscht.