Hallo an alle,

gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In den 
Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt auch kein 
Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem Upsize-Tool ist 
die Arbeit ja nicht getan. Zumal die Aussage im Raum steht, dass die 
Umstellung für jeden einzelnen Programmierer moderat ausfällt, in dem man 
die Verwendung der PGDBE in Anlehnung die DBFNTX emuliert. Aber davon sehe 
ich nichts und die Hilfe ist noch von viel "TBD" ausgefüllt.

Ich würde es aktuell für äußerst problematisch halten, für die angedachte 
Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB 
DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal so 
oder mal so benutzen kann.

Vielleicht habe ich auch nur etwas übersehen?

Gruß
PSP

Hallo Michael,

ich ertappe mich, dass ich nun schon den ganzen Vormittag über diesen 
Post nachdenke ... ist es nicht zu spät auf diesen Post zu antworten?

Und gerade habe ich gedacht: nöh.

Also, ich hoffe eigentlich, dass schon alles bekannt ist ...

Was bedeutet sinnvolle Beispiele?
Ich versuche mal ein paar Anregungen zu geben.
Warum muss/soll es sinnvolle Beispiele geben? Ist das notwendig? Das ist 
provokativ, aber ich gebe zu überlegen, dass die PGDBE ja nur der 
Austausch des Datenspeicher (Storage) ist. Anstatt in DBF/CDX/NTX wird 
eben in eine PostgreSQL Datenbank geschrieben und gelesen. Am Code muss 
ich ja nichts ändern. Die dbSkip(), SKIP, GO BOTTOM, ... das Alles (dazu 
sagt man auch ISAM Navigation) funktioniert wie vorher auch ... wie 
gesagt, nur dass die Daten nun in der PostgreSQL Datenbank liegen.

Man muss ja nicht zeigen, dass man eine Tabelle (unsere DBF) öffnen muss 
und sortieren kann und suchen kann und dergleichen.

Aber es gibt dennoch ein umfangreiches Beispiel, das die PGDBE dennoch 
ganz gut zeigt: das MDI Beispiel (zu finden in
C:\Users\<user>\Documents\Xbase++\source\samples\apps\mdidemo)
kennt man ja. Viele haben es als Startpunkt genommen. Und genau dieses 
Beipiel haben wir nach PDGBE portiert. Bitte lade das Projekt und suche 
sämtliche Vorkommen von USE_POSTGRES. Das sind alle Stellen im Code, die 
angepasst werden mussten, um mit der PostgreSQL Datenbank zu funktionieren.

Bitte ein Define USE_POSTGRES im code verwenden, neu compilieren (orher 
die Daten auf die PostgreSQL Datenbank migireren) und laufen lassen. Das 
war's.

Also: ISAM auf einer SQL Datenbank. Keine Änderung des gewohnten 
Programmierstils, aber die Sicherheit und Zuverlässigkeit eines SQL 
Servers nutzen.

 > Es gibt
 > auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
 > Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
 > steht, dass die Umstellung für jeden einzelnen Programmierer moderat
 > ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
 > emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
 > "TBD" ausgefüllt.
Siehe oben.
Aber es gibt in der Doku sehr viel Infomration, wie man PostgreSQL 
Server installiert, Datentypen, wie die Daten migriert werden, 
Einschränkungen, die Portierung von MDIDEMO, Konfiguartion, ... 
eigentlich alles. ... Aber ja, es gibt auch Lücken in der Doku.

 > Ich würde es aktuell für äußerst problematisch halten, für die
 > angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
 > DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
 > so oder mal so benutzen kann.
Verstehe ich nicht. Mach es wie im MDIDEMO gezeigt. Dann ist man für 
beide Welten (DBF und SQL) gerüstet und es ist nur eine Frage eines 
Define, wo die Daten herkommen.

Grüße,
Frank

PS: So, jetzt muss ich nicht mehr dran denken.

PSPS: soeben ist ein neues Update erschienen (vor 10 Minuten), das 
sämtliche PGDBE PDRs behebt.



On 13.11.2015 10:00, Michael Papst wrote:
> Hallo an alle,
>
> gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In
> den Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt
> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
> "TBD" ausgefüllt.
>
> Ich würde es aktuell für äußerst problematisch halten, für die
> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
> so oder mal so benutzen kann.
>
> Vielleicht habe ich auch nur etwas übersehen?
>
> Gruß
> PSP

Hallo Frank,

das schrieb Michael im November 2015(!). Und ich muß gestehen, das ich 
die aktuelle Doku zur 2.0 auch mehr als 1 Jahr später immer noch als 
sehr, sehr unvollständig empfinde.

Das hat nicht nur etwas damit zu tun, das Steffen vor mehr als einem 
Jahr (oder waren das schon zwei? Ich glaube, ja) zugesagt hat, es würde 
im darauffolgenden Frühjahr eine exzellente Doku zu  Xbase++ und 
Postgres und der Überführung von dbf-Projekten nach SQL geben, mehr als 
50 Seiten Umfang, die sei fertig geschrieben, müsse nur noch auf deutsch 
übersetzt werden.

Das hat auch damit zu tun, das ich massive Probleme mit der Doku habe. 
Ich persönlich empfinde die als unübersichtlich und unvollständig. In 
der alten Doku konnte ich zu jeder Klasse den Klassenbaum aufklappen. 
Und dort sofort erkennen, welche Methoden ich dort nutzen konnte. Heute 
gibt es das nur noch rudimentär (bitte verzeih diesen Ausdruck). Die 
wichtigsten Methoden werden aufgelistet, aber die Fülle ist nicht 
erkennbar. Gerade dann, wenn ich eine Klasse nutze mit der ich bislang 
noch wenig Erfahrungen habe, dann steh ich da so ungefähr wie Ochs vorm 
Berge.

Jan

Am 31.03.2017 um 15:00 schrieb Frank Grossheinrich:
> Hallo Michael,
>
> ich ertappe mich, dass ich nun schon den ganzen Vormittag über diesen
> Post nachdenke ... ist es nicht zu spät auf diesen Post zu antworten?
>
> Und gerade habe ich gedacht: nöh.
>
> Also, ich hoffe eigentlich, dass schon alles bekannt ist ...
>
> Was bedeutet sinnvolle Beispiele?
> Ich versuche mal ein paar Anregungen zu geben.
> Warum muss/soll es sinnvolle Beispiele geben? Ist das notwendig? Das ist
> provokativ, aber ich gebe zu überlegen, dass die PGDBE ja nur der
> Austausch des Datenspeicher (Storage) ist. Anstatt in DBF/CDX/NTX wird
> eben in eine PostgreSQL Datenbank geschrieben und gelesen. Am Code muss
> ich ja nichts ändern. Die dbSkip(), SKIP, GO BOTTOM, ... das Alles (dazu
> sagt man auch ISAM Navigation) funktioniert wie vorher auch ... wie
> gesagt, nur dass die Daten nun in der PostgreSQL Datenbank liegen.
>
> Man muss ja nicht zeigen, dass man eine Tabelle (unsere DBF) öffnen muss
> und sortieren kann und suchen kann und dergleichen.
>
> Aber es gibt dennoch ein umfangreiches Beispiel, das die PGDBE dennoch
> ganz gut zeigt: das MDI Beispiel (zu finden in
> C:\Users\<user>\Documents\Xbase++\source\samples\apps\mdidemo)
> kennt man ja. Viele haben es als Startpunkt genommen. Und genau dieses
> Beipiel haben wir nach PDGBE portiert. Bitte lade das Projekt und suche
> sämtliche Vorkommen von USE_POSTGRES. Das sind alle Stellen im Code, die
> angepasst werden mussten, um mit der PostgreSQL Datenbank zu funktionieren.
>
> Bitte ein Define USE_POSTGRES im code verwenden, neu compilieren (orher
> die Daten auf die PostgreSQL Datenbank migireren) und laufen lassen. Das
> war's.
>
> Also: ISAM auf einer SQL Datenbank. Keine Änderung des gewohnten
> Programmierstils, aber die Sicherheit und Zuverlässigkeit eines SQL
> Servers nutzen.
>
>> Es gibt
>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>> "TBD" ausgefüllt.
> Siehe oben.
> Aber es gibt in der Doku sehr viel Infomration, wie man PostgreSQL
> Server installiert, Datentypen, wie die Daten migriert werden,
> Einschränkungen, die Portierung von MDIDEMO, Konfiguartion, ...
> eigentlich alles. ... Aber ja, es gibt auch Lücken in der Doku.
>
>> Ich würde es aktuell für äußerst problematisch halten, für die
>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>> so oder mal so benutzen kann.
> Verstehe ich nicht. Mach es wie im MDIDEMO gezeigt. Dann ist man für
> beide Welten (DBF und SQL) gerüstet und es ist nur eine Frage eines
> Define, wo die Daten herkommen.
>
> Grüße,
> Frank
>
> PS: So, jetzt muss ich nicht mehr dran denken.
>
> PSPS: soeben ist ein neues Update erschienen (vor 10 Minuten), das
> sämtliche PGDBE PDRs behebt.
>
>
>
> On 13.11.2015 10:00, Michael Papst wrote:
>> Hallo an alle,
>>
>> gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In
>> den Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt
>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>> "TBD" ausgefüllt.
>>
>> Ich würde es aktuell für äußerst problematisch halten, für die
>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>> so oder mal so benutzen kann.
>>
>> Vielleicht habe ich auch nur etwas übersehen?
>>
>> Gruß
>> PSP
>

Hey Jan,

schon wieder ich ...
Ich kann das alles verstehen.
Glaube mir, wir geben sogar monatlich VIEL Geld aus für Doku. Monatlich!
Wir selbst lesen total viel Doku (für viele Dinge).

Aber wir haben noch nicht den richtigen effizienten Weg gefunden mit den 
externen Kräften klar und koordiniert zu arbeiten. Hier lernen wir  noch 
selbst. Unser Anspruch ist natürlcih mehr und wir sind nicht stolz. 
Manchmal müssen wir abwägen und versuchen dennoch am Ball zu bleiben. 
Ein Spagat, der nicht immer gelingt.

Wir bleiben trotzdem dran,

Frank

On 31.03.2017 22:33, Jan Escholt wrote:
> Hallo Frank,
>
> das schrieb Michael im November 2015(!). Und ich muß gestehen, das ich
> die aktuelle Doku zur 2.0 auch mehr als 1 Jahr später immer noch als
> sehr, sehr unvollständig empfinde.
>
> Das hat nicht nur etwas damit zu tun, das Steffen vor mehr als einem
> Jahr (oder waren das schon zwei? Ich glaube, ja) zugesagt hat, es würde
> im darauffolgenden Frühjahr eine exzellente Doku zu  Xbase++ und
> Postgres und der Überführung von dbf-Projekten nach SQL geben, mehr als
> 50 Seiten Umfang, die sei fertig geschrieben, müsse nur noch auf deutsch
> übersetzt werden.
>
> Das hat auch damit zu tun, das ich massive Probleme mit der Doku habe.
> Ich persönlich empfinde die als unübersichtlich und unvollständig. In
> der alten Doku konnte ich zu jeder Klasse den Klassenbaum aufklappen.
> Und dort sofort erkennen, welche Methoden ich dort nutzen konnte. Heute
> gibt es das nur noch rudimentär (bitte verzeih diesen Ausdruck). Die
> wichtigsten Methoden werden aufgelistet, aber die Fülle ist nicht
> erkennbar. Gerade dann, wenn ich eine Klasse nutze mit der ich bislang
> noch wenig Erfahrungen habe, dann steh ich da so ungefähr wie Ochs vorm
> Berge.
>
> Jan
>
> Am 31.03.2017 um 15:00 schrieb Frank Grossheinrich:
>> Hallo Michael,
>>
>> ich ertappe mich, dass ich nun schon den ganzen Vormittag über diesen
>> Post nachdenke ... ist es nicht zu spät auf diesen Post zu antworten?
>>
>> Und gerade habe ich gedacht: nöh.
>>
>> Also, ich hoffe eigentlich, dass schon alles bekannt ist ...
>>
>> Was bedeutet sinnvolle Beispiele?
>> Ich versuche mal ein paar Anregungen zu geben.
>> Warum muss/soll es sinnvolle Beispiele geben? Ist das notwendig? Das ist
>> provokativ, aber ich gebe zu überlegen, dass die PGDBE ja nur der
>> Austausch des Datenspeicher (Storage) ist. Anstatt in DBF/CDX/NTX wird
>> eben in eine PostgreSQL Datenbank geschrieben und gelesen. Am Code muss
>> ich ja nichts ändern. Die dbSkip(), SKIP, GO BOTTOM, ... das Alles (dazu
>> sagt man auch ISAM Navigation) funktioniert wie vorher auch ... wie
>> gesagt, nur dass die Daten nun in der PostgreSQL Datenbank liegen.
>>
>> Man muss ja nicht zeigen, dass man eine Tabelle (unsere DBF) öffnen muss
>> und sortieren kann und suchen kann und dergleichen.
>>
>> Aber es gibt dennoch ein umfangreiches Beispiel, das die PGDBE dennoch
>> ganz gut zeigt: das MDI Beispiel (zu finden in
>> C:\Users\<user>\Documents\Xbase++\source\samples\apps\mdidemo)
>> kennt man ja. Viele haben es als Startpunkt genommen. Und genau dieses
>> Beipiel haben wir nach PDGBE portiert. Bitte lade das Projekt und suche
>> sämtliche Vorkommen von USE_POSTGRES. Das sind alle Stellen im Code, die
>> angepasst werden mussten, um mit der PostgreSQL Datenbank zu
>> funktionieren.
>>
>> Bitte ein Define USE_POSTGRES im code verwenden, neu compilieren (orher
>> die Daten auf die PostgreSQL Datenbank migireren) und laufen lassen. Das
>> war's.
>>
>> Also: ISAM auf einer SQL Datenbank. Keine Änderung des gewohnten
>> Programmierstils, aber die Sicherheit und Zuverlässigkeit eines SQL
>> Servers nutzen.
>>
>>> Es gibt
>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>> "TBD" ausgefüllt.
>> Siehe oben.
>> Aber es gibt in der Doku sehr viel Infomration, wie man PostgreSQL
>> Server installiert, Datentypen, wie die Daten migriert werden,
>> Einschränkungen, die Portierung von MDIDEMO, Konfiguartion, ...
>> eigentlich alles. ... Aber ja, es gibt auch Lücken in der Doku.
>>
>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>>> so oder mal so benutzen kann.
>> Verstehe ich nicht. Mach es wie im MDIDEMO gezeigt. Dann ist man für
>> beide Welten (DBF und SQL) gerüstet und es ist nur eine Frage eines
>> Define, wo die Daten herkommen.
>>
>> Grüße,
>> Frank
>>
>> PS: So, jetzt muss ich nicht mehr dran denken.
>>
>> PSPS: soeben ist ein neues Update erschienen (vor 10 Minuten), das
>> sämtliche PGDBE PDRs behebt.
>>
>>
>>
>> On 13.11.2015 10:00, Michael Papst wrote:
>>> Hallo an alle,
>>>
>>> gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In
>>> den Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt
>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>> "TBD" ausgefüllt.
>>>
>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>>> so oder mal so benutzen kann.
>>>
>>> Vielleicht habe ich auch nur etwas übersehen?
>>>
>>> Gruß
>>> PSP
>>

Hallo Frank,

meine Vorschläge für die Doku:

- Viele Samples sind immer noch (die in der Doku) sind immer noch VIO. 
Ja klar,es kommen auch heute noch stapelweise Clipperianer zu Xbase++. 
Aber sehr viele Xbase++ler sind eben auch schon GUI. Und da fehlen in 
der Doku viele Codebeispiele.

- Baut bitte den Treeview wieder ein. Das macht das Leben wirklich ganz 
extrem einfacher.

Und ab und an würde ich mir mal was ausführlicheres wünschen zu manchen 
Themen. Wie die angeprochene PostgreSQL-Doku, oder was ausführliches mit 
möglichst verschiedenen Anwendungsbeispielen zu den DataObjects. So, wie 
die Doku im Moment ist, verliert man sehr viel Zeit damit überhaupt zu 
verstehen, was da los ist, wie das geht, wie das einsetzbar sein könnte.

Naja, und wenn Ihr dazu kommt (ich weiß, Ihr kommt immer wieder dazu  
), einfach die Doku weiter vervollständigen. Aber wenn Ihr die beiden 
Punkte oben hinbekommt, ist schon extrem viel gewonnen.

Jan

Am 04.04.2017 um 18:15 schrieb Frank Grossheinrich:
> Hey Jan,
>
> schon wieder ich ...
> Ich kann das alles verstehen.
> Glaube mir, wir geben sogar monatlich VIEL Geld aus für Doku. Monatlich!
> Wir selbst lesen total viel Doku (für viele Dinge).
>
> Aber wir haben noch nicht den richtigen effizienten Weg gefunden mit den
> externen Kräften klar und koordiniert zu arbeiten. Hier lernen wir  noch
> selbst. Unser Anspruch ist natürlcih mehr und wir sind nicht stolz.
> Manchmal müssen wir abwägen und versuchen dennoch am Ball zu bleiben.
> Ein Spagat, der nicht immer gelingt.
>
> Wir bleiben trotzdem dran,
>
> Frank
>
> On 31.03.2017 22:33, Jan Escholt wrote:
>> Hallo Frank,
>>
>> das schrieb Michael im November 2015(!). Und ich muß gestehen, das ich
>> die aktuelle Doku zur 2.0 auch mehr als 1 Jahr später immer noch als
>> sehr, sehr unvollständig empfinde.
>>
>> Das hat nicht nur etwas damit zu tun, das Steffen vor mehr als einem
>> Jahr (oder waren das schon zwei? Ich glaube, ja) zugesagt hat, es würde
>> im darauffolgenden Frühjahr eine exzellente Doku zu  Xbase++ und
>> Postgres und der Überführung von dbf-Projekten nach SQL geben, mehr als
>> 50 Seiten Umfang, die sei fertig geschrieben, müsse nur noch auf deutsch
>> übersetzt werden.
>>
>> Das hat auch damit zu tun, das ich massive Probleme mit der Doku habe.
>> Ich persönlich empfinde die als unübersichtlich und unvollständig. In
>> der alten Doku konnte ich zu jeder Klasse den Klassenbaum aufklappen.
>> Und dort sofort erkennen, welche Methoden ich dort nutzen konnte. Heute
>> gibt es das nur noch rudimentär (bitte verzeih diesen Ausdruck). Die
>> wichtigsten Methoden werden aufgelistet, aber die Fülle ist nicht
>> erkennbar. Gerade dann, wenn ich eine Klasse nutze mit der ich bislang
>> noch wenig Erfahrungen habe, dann steh ich da so ungefähr wie Ochs vorm
>> Berge.
>>
>> Jan
>>
>> Am 31.03.2017 um 15:00 schrieb Frank Grossheinrich:
>>> Hallo Michael,
>>>
>>> ich ertappe mich, dass ich nun schon den ganzen Vormittag über diesen
>>> Post nachdenke ... ist es nicht zu spät auf diesen Post zu antworten?
>>>
>>> Und gerade habe ich gedacht: nöh.
>>>
>>> Also, ich hoffe eigentlich, dass schon alles bekannt ist ...
>>>
>>> Was bedeutet sinnvolle Beispiele?
>>> Ich versuche mal ein paar Anregungen zu geben.
>>> Warum muss/soll es sinnvolle Beispiele geben? Ist das notwendig? Das ist
>>> provokativ, aber ich gebe zu überlegen, dass die PGDBE ja nur der
>>> Austausch des Datenspeicher (Storage) ist. Anstatt in DBF/CDX/NTX wird
>>> eben in eine PostgreSQL Datenbank geschrieben und gelesen. Am Code muss
>>> ich ja nichts ändern. Die dbSkip(), SKIP, GO BOTTOM, ... das Alles (dazu
>>> sagt man auch ISAM Navigation) funktioniert wie vorher auch ... wie
>>> gesagt, nur dass die Daten nun in der PostgreSQL Datenbank liegen.
>>>
>>> Man muss ja nicht zeigen, dass man eine Tabelle (unsere DBF) öffnen muss
>>> und sortieren kann und suchen kann und dergleichen.
>>>
>>> Aber es gibt dennoch ein umfangreiches Beispiel, das die PGDBE dennoch
>>> ganz gut zeigt: das MDI Beispiel (zu finden in
>>> C:\Users\<user>\Documents\Xbase++\source\samples\apps\mdidemo)
>>> kennt man ja. Viele haben es als Startpunkt genommen. Und genau dieses
>>> Beipiel haben wir nach PDGBE portiert. Bitte lade das Projekt und suche
>>> sämtliche Vorkommen von USE_POSTGRES. Das sind alle Stellen im Code, die
>>> angepasst werden mussten, um mit der PostgreSQL Datenbank zu
>>> funktionieren.
>>>
>>> Bitte ein Define USE_POSTGRES im code verwenden, neu compilieren (orher
>>> die Daten auf die PostgreSQL Datenbank migireren) und laufen lassen. Das
>>> war's.
>>>
>>> Also: ISAM auf einer SQL Datenbank. Keine Änderung des gewohnten
>>> Programmierstils, aber die Sicherheit und Zuverlässigkeit eines SQL
>>> Servers nutzen.
>>>
>>>> Es gibt
>>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>>> "TBD" ausgefüllt.
>>> Siehe oben.
>>> Aber es gibt in der Doku sehr viel Infomration, wie man PostgreSQL
>>> Server installiert, Datentypen, wie die Daten migriert werden,
>>> Einschränkungen, die Portierung von MDIDEMO, Konfiguartion, ...
>>> eigentlich alles. ... Aber ja, es gibt auch Lücken in der Doku.
>>>
>>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>>>> so oder mal so benutzen kann.
>>> Verstehe ich nicht. Mach es wie im MDIDEMO gezeigt. Dann ist man für
>>> beide Welten (DBF und SQL) gerüstet und es ist nur eine Frage eines
>>> Define, wo die Daten herkommen.
>>>
>>> Grüße,
>>> Frank
>>>
>>> PS: So, jetzt muss ich nicht mehr dran denken.
>>>
>>> PSPS: soeben ist ein neues Update erschienen (vor 10 Minuten), das
>>> sämtliche PGDBE PDRs behebt.
>>>
>>>
>>>
>>> On 13.11.2015 10:00, Michael Papst wrote:
>>>> Hallo an alle,
>>>>
>>>> gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In
>>>> den Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt
>>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>>> "TBD" ausgefüllt.
>>>>
>>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>>>> so oder mal so benutzen kann.
>>>>
>>>> Vielleicht habe ich auch nur etwas übersehen?
>>>>
>>>> Gruß
>>>> PSP
>>>
>

Eine Geschichte aus dem Nähkästchen: wir haben seit Monaten eine Doku 
für die Installation des WAA unter Win 10 (das geht nämlich dort ein 
wenig anders). Die habe ich redigiert und brauche sie auch immer wieder 
mal. Der Teil ist eigentlich fertig.

Nun muss der Teil in die aktuelle Doku eingebunden werden. Und dafür 
haben wir immer noch nicht die Zeit gefunden. Aber ich werde das nun mal 
forcieren. Wir haben hier Dinge liegen, die soooo nützlich wären, wenn 
es denn Jemand wüsste.

Treeview?? Welchen Treeview meinst du? Kläre mich mal bitte kurz auf. 
Dann schaue ich.

Gruß, Frank

On 04.04.2017 20:32, Jan Escholt wrote:
> Hallo Frank,
>
> meine Vorschläge für die Doku:
>
> - Viele Samples sind immer noch (die in der Doku) sind immer noch VIO.
> Ja klar,es kommen auch heute noch stapelweise Clipperianer zu Xbase++.
> Aber sehr viele Xbase++ler sind eben auch schon GUI. Und da fehlen in
> der Doku viele Codebeispiele.
>
> - Baut bitte den Treeview wieder ein. Das macht das Leben wirklich ganz
> extrem einfacher.
>
> Und ab und an würde ich mir mal was ausführlicheres wünschen zu manchen
> Themen. Wie die angeprochene PostgreSQL-Doku, oder was ausführliches mit
> möglichst verschiedenen Anwendungsbeispielen zu den DataObjects. So, wie
> die Doku im Moment ist, verliert man sehr viel Zeit damit überhaupt zu
> verstehen, was da los ist, wie das geht, wie das einsetzbar sein könnte.
>
> Naja, und wenn Ihr dazu kommt (ich weiß, Ihr kommt immer wieder dazu 
> ), einfach die Doku weiter vervollständigen. Aber wenn Ihr die beiden
> Punkte oben hinbekommt, ist schon extrem viel gewonnen.
>
> Jan
>
> Am 04.04.2017 um 18:15 schrieb Frank Grossheinrich:
>> Hey Jan,
>>
>> schon wieder ich ...
>> Ich kann das alles verstehen.
>> Glaube mir, wir geben sogar monatlich VIEL Geld aus für Doku. Monatlich!
>> Wir selbst lesen total viel Doku (für viele Dinge).
>>
>> Aber wir haben noch nicht den richtigen effizienten Weg gefunden mit den
>> externen Kräften klar und koordiniert zu arbeiten. Hier lernen wir  noch
>> selbst. Unser Anspruch ist natürlcih mehr und wir sind nicht stolz.
>> Manchmal müssen wir abwägen und versuchen dennoch am Ball zu bleiben.
>> Ein Spagat, der nicht immer gelingt.
>>
>> Wir bleiben trotzdem dran,
>>
>> Frank
>>
>> On 31.03.2017 22:33, Jan Escholt wrote:
>>> Hallo Frank,
>>>
>>> das schrieb Michael im November 2015(!). Und ich muß gestehen, das ich
>>> die aktuelle Doku zur 2.0 auch mehr als 1 Jahr später immer noch als
>>> sehr, sehr unvollständig empfinde.
>>>
>>> Das hat nicht nur etwas damit zu tun, das Steffen vor mehr als einem
>>> Jahr (oder waren das schon zwei? Ich glaube, ja) zugesagt hat, es würde
>>> im darauffolgenden Frühjahr eine exzellente Doku zu  Xbase++ und
>>> Postgres und der Überführung von dbf-Projekten nach SQL geben, mehr als
>>> 50 Seiten Umfang, die sei fertig geschrieben, müsse nur noch auf deutsch
>>> übersetzt werden.
>>>
>>> Das hat auch damit zu tun, das ich massive Probleme mit der Doku habe.
>>> Ich persönlich empfinde die als unübersichtlich und unvollständig. In
>>> der alten Doku konnte ich zu jeder Klasse den Klassenbaum aufklappen.
>>> Und dort sofort erkennen, welche Methoden ich dort nutzen konnte. Heute
>>> gibt es das nur noch rudimentär (bitte verzeih diesen Ausdruck). Die
>>> wichtigsten Methoden werden aufgelistet, aber die Fülle ist nicht
>>> erkennbar. Gerade dann, wenn ich eine Klasse nutze mit der ich bislang
>>> noch wenig Erfahrungen habe, dann steh ich da so ungefähr wie Ochs vorm
>>> Berge.
>>>
>>> Jan
>>>
>>> Am 31.03.2017 um 15:00 schrieb Frank Grossheinrich:
>>>> Hallo Michael,
>>>>
>>>> ich ertappe mich, dass ich nun schon den ganzen Vormittag über diesen
>>>> Post nachdenke ... ist es nicht zu spät auf diesen Post zu antworten?
>>>>
>>>> Und gerade habe ich gedacht: nöh.
>>>>
>>>> Also, ich hoffe eigentlich, dass schon alles bekannt ist ...
>>>>
>>>> Was bedeutet sinnvolle Beispiele?
>>>> Ich versuche mal ein paar Anregungen zu geben.
>>>> Warum muss/soll es sinnvolle Beispiele geben? Ist das notwendig? Das
>>>> ist
>>>> provokativ, aber ich gebe zu überlegen, dass die PGDBE ja nur der
>>>> Austausch des Datenspeicher (Storage) ist. Anstatt in DBF/CDX/NTX wird
>>>> eben in eine PostgreSQL Datenbank geschrieben und gelesen. Am Code muss
>>>> ich ja nichts ändern. Die dbSkip(), SKIP, GO BOTTOM, ... das Alles
>>>> (dazu
>>>> sagt man auch ISAM Navigation) funktioniert wie vorher auch ... wie
>>>> gesagt, nur dass die Daten nun in der PostgreSQL Datenbank liegen.
>>>>
>>>> Man muss ja nicht zeigen, dass man eine Tabelle (unsere DBF) öffnen
>>>> muss
>>>> und sortieren kann und suchen kann und dergleichen.
>>>>
>>>> Aber es gibt dennoch ein umfangreiches Beispiel, das die PGDBE dennoch
>>>> ganz gut zeigt: das MDI Beispiel (zu finden in
>>>> C:\Users\<user>\Documents\Xbase++\source\samples\apps\mdidemo)
>>>> kennt man ja. Viele haben es als Startpunkt genommen. Und genau dieses
>>>> Beipiel haben wir nach PDGBE portiert. Bitte lade das Projekt und suche
>>>> sämtliche Vorkommen von USE_POSTGRES. Das sind alle Stellen im Code,
>>>> die
>>>> angepasst werden mussten, um mit der PostgreSQL Datenbank zu
>>>> funktionieren.
>>>>
>>>> Bitte ein Define USE_POSTGRES im code verwenden, neu compilieren (orher
>>>> die Daten auf die PostgreSQL Datenbank migireren) und laufen lassen.
>>>> Das
>>>> war's.
>>>>
>>>> Also: ISAM auf einer SQL Datenbank. Keine Änderung des gewohnten
>>>> Programmierstils, aber die Sicherheit und Zuverlässigkeit eines SQL
>>>> Servers nutzen.
>>>>
>>>>> Es gibt
>>>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>>>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>>>> "TBD" ausgefüllt.
>>>> Siehe oben.
>>>> Aber es gibt in der Doku sehr viel Infomration, wie man PostgreSQL
>>>> Server installiert, Datentypen, wie die Daten migriert werden,
>>>> Einschränkungen, die Portierung von MDIDEMO, Konfiguartion, ...
>>>> eigentlich alles. ... Aber ja, es gibt auch Lücken in der Doku.
>>>>
>>>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>>>>> so oder mal so benutzen kann.
>>>> Verstehe ich nicht. Mach es wie im MDIDEMO gezeigt. Dann ist man für
>>>> beide Welten (DBF und SQL) gerüstet und es ist nur eine Frage eines
>>>> Define, wo die Daten herkommen.
>>>>
>>>> Grüße,
>>>> Frank
>>>>
>>>> PS: So, jetzt muss ich nicht mehr dran denken.
>>>>
>>>> PSPS: soeben ist ein neues Update erschienen (vor 10 Minuten), das
>>>> sämtliche PGDBE PDRs behebt.
>>>>
>>>>
>>>>
>>>> On 13.11.2015 10:00, Michael Papst wrote:
>>>>> Hallo an alle,
>>>>>
>>>>> gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In
>>>>> den Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt
>>>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>>>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>>>> "TBD" ausgefüllt.
>>>>>
>>>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>>>>> so oder mal so benutzen kann.
>>>>>
>>>>> Vielleicht habe ich auch nur etwas übersehen?
>>>>>
>>>>> Gruß
>>>>> PSP
>>>>
>>

Hallo Frank,
sorry, da war ich mit den Begrifflichkeiten wohl etwas neben der Spur. 
Ich meinte "Klassenbaum".

Jan

Am 06.04.2017 um 18:51 schrieb Frank Grossheinrich:
> Eine Geschichte aus dem Nähkästchen: wir haben seit Monaten eine Doku 
> für die Installation des WAA unter Win 10 (das geht nämlich dort ein 
> wenig anders). Die habe ich redigiert und brauche sie auch immer wieder 
> mal. Der Teil ist eigentlich fertig.
> 
> Nun muss der Teil in die aktuelle Doku eingebunden werden. Und dafür 
> haben wir immer noch nicht die Zeit gefunden. Aber ich werde das nun mal 
> forcieren. Wir haben hier Dinge liegen, die soooo nützlich wären, wenn 
> es denn Jemand wüsste.
> 
> Treeview?? Welchen Treeview meinst du? Kläre mich mal bitte kurz auf. 
> Dann schaue ich.
> 
> Gruß, Frank
> 
> On 04.04.2017 20:32, Jan Escholt wrote:
>> Hallo Frank,
>>
>> meine Vorschläge für die Doku:
>>
>> - Viele Samples sind immer noch (die in der Doku) sind immer noch VIO.
>> Ja klar,es kommen auch heute noch stapelweise Clipperianer zu Xbase++.
>> Aber sehr viele Xbase++ler sind eben auch schon GUI. Und da fehlen in
>> der Doku viele Codebeispiele.
>>
>> - Baut bitte den Treeview wieder ein. Das macht das Leben wirklich ganz
>> extrem einfacher.
>>
>> Und ab und an würde ich mir mal was ausführlicheres wünschen zu manchen
>> Themen. Wie die angeprochene PostgreSQL-Doku, oder was ausführliches mit
>> möglichst verschiedenen Anwendungsbeispielen zu den DataObjects. So, wie
>> die Doku im Moment ist, verliert man sehr viel Zeit damit überhaupt zu
>> verstehen, was da los ist, wie das geht, wie das einsetzbar sein könnte.
>>
>> Naja, und wenn Ihr dazu kommt (ich weiß, Ihr kommt immer wieder dazu 
>> ), einfach die Doku weiter vervollständigen. Aber wenn Ihr die beiden
>> Punkte oben hinbekommt, ist schon extrem viel gewonnen.
>>
>> Jan
>>
>> Am 04.04.2017 um 18:15 schrieb Frank Grossheinrich:
>>> Hey Jan,
>>>
>>> schon wieder ich ...
>>> Ich kann das alles verstehen.
>>> Glaube mir, wir geben sogar monatlich VIEL Geld aus für Doku. Monatlich!
>>> Wir selbst lesen total viel Doku (für viele Dinge).
>>>
>>> Aber wir haben noch nicht den richtigen effizienten Weg gefunden mit den
>>> externen Kräften klar und koordiniert zu arbeiten. Hier lernen wir  noch
>>> selbst. Unser Anspruch ist natürlcih mehr und wir sind nicht stolz.
>>> Manchmal müssen wir abwägen und versuchen dennoch am Ball zu bleiben.
>>> Ein Spagat, der nicht immer gelingt.
>>>
>>> Wir bleiben trotzdem dran,
>>>
>>> Frank
>>>
>>> On 31.03.2017 22:33, Jan Escholt wrote:
>>>> Hallo Frank,
>>>>
>>>> das schrieb Michael im November 2015(!). Und ich muß gestehen, das ich
>>>> die aktuelle Doku zur 2.0 auch mehr als 1 Jahr später immer noch als
>>>> sehr, sehr unvollständig empfinde.
>>>>
>>>> Das hat nicht nur etwas damit zu tun, das Steffen vor mehr als einem
>>>> Jahr (oder waren das schon zwei? Ich glaube, ja) zugesagt hat, es würde
>>>> im darauffolgenden Frühjahr eine exzellente Doku zu  Xbase++ und
>>>> Postgres und der Überführung von dbf-Projekten nach SQL geben, mehr als
>>>> 50 Seiten Umfang, die sei fertig geschrieben, müsse nur noch auf 
>>>> deutsch
>>>> übersetzt werden.
>>>>
>>>> Das hat auch damit zu tun, das ich massive Probleme mit der Doku habe.
>>>> Ich persönlich empfinde die als unübersichtlich und unvollständig. In
>>>> der alten Doku konnte ich zu jeder Klasse den Klassenbaum aufklappen.
>>>> Und dort sofort erkennen, welche Methoden ich dort nutzen konnte. Heute
>>>> gibt es das nur noch rudimentär (bitte verzeih diesen Ausdruck). Die
>>>> wichtigsten Methoden werden aufgelistet, aber die Fülle ist nicht
>>>> erkennbar. Gerade dann, wenn ich eine Klasse nutze mit der ich bislang
>>>> noch wenig Erfahrungen habe, dann steh ich da so ungefähr wie Ochs vorm
>>>> Berge.
>>>>
>>>> Jan
>>>>
>>>> Am 31.03.2017 um 15:00 schrieb Frank Grossheinrich:
>>>>> Hallo Michael,
>>>>>
>>>>> ich ertappe mich, dass ich nun schon den ganzen Vormittag über diesen
>>>>> Post nachdenke ... ist es nicht zu spät auf diesen Post zu antworten?
>>>>>
>>>>> Und gerade habe ich gedacht: nöh.
>>>>>
>>>>> Also, ich hoffe eigentlich, dass schon alles bekannt ist ...
>>>>>
>>>>> Was bedeutet sinnvolle Beispiele?
>>>>> Ich versuche mal ein paar Anregungen zu geben.
>>>>> Warum muss/soll es sinnvolle Beispiele geben? Ist das notwendig? Das
>>>>> ist
>>>>> provokativ, aber ich gebe zu überlegen, dass die PGDBE ja nur der
>>>>> Austausch des Datenspeicher (Storage) ist. Anstatt in DBF/CDX/NTX wird
>>>>> eben in eine PostgreSQL Datenbank geschrieben und gelesen. Am Code 
>>>>> muss
>>>>> ich ja nichts ändern. Die dbSkip(), SKIP, GO BOTTOM, ... das Alles
>>>>> (dazu
>>>>> sagt man auch ISAM Navigation) funktioniert wie vorher auch ... wie
>>>>> gesagt, nur dass die Daten nun in der PostgreSQL Datenbank liegen.
>>>>>
>>>>> Man muss ja nicht zeigen, dass man eine Tabelle (unsere DBF) öffnen
>>>>> muss
>>>>> und sortieren kann und suchen kann und dergleichen.
>>>>>
>>>>> Aber es gibt dennoch ein umfangreiches Beispiel, das die PGDBE dennoch
>>>>> ganz gut zeigt: das MDI Beispiel (zu finden in
>>>>> C:\Users\<user>\Documents\Xbase++\source\samples\apps\mdidemo)
>>>>> kennt man ja. Viele haben es als Startpunkt genommen. Und genau dieses
>>>>> Beipiel haben wir nach PDGBE portiert. Bitte lade das Projekt und 
>>>>> suche
>>>>> sämtliche Vorkommen von USE_POSTGRES. Das sind alle Stellen im Code,
>>>>> die
>>>>> angepasst werden mussten, um mit der PostgreSQL Datenbank zu
>>>>> funktionieren.
>>>>>
>>>>> Bitte ein Define USE_POSTGRES im code verwenden, neu compilieren 
>>>>> (orher
>>>>> die Daten auf die PostgreSQL Datenbank migireren) und laufen lassen.
>>>>> Das
>>>>> war's.
>>>>>
>>>>> Also: ISAM auf einer SQL Datenbank. Keine Änderung des gewohnten
>>>>> Programmierstils, aber die Sicherheit und Zuverlässigkeit eines SQL
>>>>> Servers nutzen.
>>>>>
>>>>>> Es gibt
>>>>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit 
>>>>>> dem
>>>>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>>>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>>>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>>>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>>>>> "TBD" ausgefüllt.
>>>>> Siehe oben.
>>>>> Aber es gibt in der Doku sehr viel Infomration, wie man PostgreSQL
>>>>> Server installiert, Datentypen, wie die Daten migriert werden,
>>>>> Einschränkungen, die Portierung von MDIDEMO, Konfiguartion, ...
>>>>> eigentlich alles. ... Aber ja, es gibt auch Lücken in der Doku.
>>>>>
>>>>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>>>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>>>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man 
>>>>>> mal
>>>>>> so oder mal so benutzen kann.
>>>>> Verstehe ich nicht. Mach es wie im MDIDEMO gezeigt. Dann ist man für
>>>>> beide Welten (DBF und SQL) gerüstet und es ist nur eine Frage eines
>>>>> Define, wo die Daten herkommen.
>>>>>
>>>>> Grüße,
>>>>> Frank
>>>>>
>>>>> PS: So, jetzt muss ich nicht mehr dran denken.
>>>>>
>>>>> PSPS: soeben ist ein neues Update erschienen (vor 10 Minuten), das
>>>>> sämtliche PGDBE PDRs behebt.
>>>>>
>>>>>
>>>>>
>>>>> On 13.11.2015 10:00, Michael Papst wrote:
>>>>>> Hallo an alle,
>>>>>>
>>>>>> gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In
>>>>>> den Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt
>>>>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit 
>>>>>> dem
>>>>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>>>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>>>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>>>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>>>>> "TBD" ausgefüllt.
>>>>>>
>>>>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>>>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>>>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man 
>>>>>> mal
>>>>>> so oder mal so benutzen kann.
>>>>>>
>>>>>> Vielleicht habe ich auch nur etwas übersehen?
>>>>>>
>>>>>> Gruß
>>>>>> PSP
>>>>>
>>>
>

Hallo Frank,

mittlerweile ist Xbase++ 2.0 weiter gediegen und gereift - aber noch immer im
Detail unzureichend.

Die Produktiv-Anwendung aus unserem Hause, die seit 1993 jeden Wandel
mitgemacht hat, gibt es aktuell für die Kunden nur in Xbase 1.9 als
Only-DBFNTX-Anwendung. In der Validierung ist die gleiche Anwendung in Xbase
2.0 weit gekommen, so dass tatsächlich darüber nachgedacht wird, dem Kunden
die Vorteile zukommen zu lassen, die nun möglich sind.

Jedoch ist auch ein Xbase 2.0-Pfad in der Testung, der auf PGDBE setzt,
gegebebenenfalls DBFNTX nutzt, wenn es nötig ist. Der Upsize-Prozess konnte
hinreichend automatisiert werden. Leider gibt es Probleme, dies intern zu
über die Funktionen der dbfupsize.dll nutzen. Daher muss die dbfupsize.exe
herhalten, was für eine einmalige Umstellung noch erträglich ist.

Mit dem Build .785 ist DbPosition und DbGoPosition funktionsfähig zurück,
wobei es Probleme mit Datenauswahlen basierend auf DbSetRelation bestehen, so
dass beim Scrollen man irgendwo im Nichts landet. DbSetFilter wurde in Bezug
auf PGDBE davor schon angefasst, arbeitet aber noch nicht zufriedenstellend,
wenn die Filter-Bedinungen komplexer werden. Das führte dazu, dass man für
die PGBDE an den wichtigen Stellen, eine permanent arbeitende Datenauswahl in
den Hintergrund stellt, die aber am wichtigsten scheitert. Die
WHERE-Bedingung im Select-Query beim use (cQuery) new wurde vollends
ignoriert, so dass anstatt der gewünschten 30 oder 60 Datensätze alle geladen
wurden. Technisch war das Query einwandfrei, da PGAdmin das gewünschte
Ergebnis lieferte. Also ist man immer noch weit von einer Umsetzung entfernt.
Manche Kunden fragen schon gar nicht mehr nach nativen SQL.

Dass die Hilfe, egal ob englisch oder deutsch noch Lücken hat, dürfte ja
weiterhin bekannt sein.

Ich hoffe, dass die oben genannten Unzulänglichkeiten in naher Zukunft
ausgebessert werden. Die Möglichkeiten lassen erahnen, wo es hingehen könnte.
Aber bei den meisten fällt eine komplette Neuentwicklung aus finanziellen und
zeitlichen Gründen einfach weg, dass man sie sofort nutzen könnte.

Gruß
Michael


On 31.03.2017 15:00:51,  wrote:
> Hallo Michael,
> 
> ich ertappe mich, dass ich nun schon den ganzen Vormittag über diesen
> Post nachdenke ... ist es nicht zu spät auf diesen Post zu antworten?
> 
> Und gerade habe ich gedacht: nöh.
> 
> Also, ich hoffe eigentlich, dass schon alles bekannt ist ...
> 
> Was bedeutet sinnvolle Beispiele?
> Ich versuche mal ein paar Anregungen zu geben.
> Warum muss/soll es sinnvolle Beispiele geben? Ist das notwendig? Das ist
> provokativ, aber ich gebe zu überlegen, dass die PGDBE ja nur der
> Austausch des Datenspeicher (Storage) ist. Anstatt in DBF/CDX/NTX wird
> eben in eine PostgreSQL Datenbank geschrieben und gelesen. Am Code muss
> ich ja nichts ändern. Die dbSkip(), SKIP, GO BOTTOM, ... das Alles (dazu
> sagt man auch ISAM Navigation) funktioniert wie vorher auch ... wie
> gesagt, nur dass die Daten nun in der PostgreSQL Datenbank liegen.
> 
> Man muss ja nicht zeigen, dass man eine Tabelle (unsere DBF) öffnen muss
> und sortieren kann und suchen kann und dergleichen.
> 
> Aber es gibt dennoch ein umfangreiches Beispiel, das die PGDBE dennoch
> ganz gut zeigt: das MDI Beispiel (zu finden in
> C:\Users\<user>\Documents\Xbase++\source\samples\apps\mdidemo)
> kennt man ja. Viele haben es als Startpunkt genommen. Und genau dieses
> Beipiel haben wir nach PDGBE portiert. Bitte lade das Projekt und suche
> sämtliche Vorkommen von USE_POSTGRES. Das sind alle Stellen im Code, die
> angepasst werden mussten, um mit der PostgreSQL Datenbank zu
> funktionieren.
> 
> Bitte ein Define USE_POSTGRES im code verwenden, neu compilieren (orher
> die Daten auf die PostgreSQL Datenbank migireren) und laufen lassen. Das
> war's.
> 
> Also: ISAM auf einer SQL Datenbank. Keine Änderung des gewohnten
> Programmierstils, aber die Sicherheit und Zuverlässigkeit eines SQL
> Servers nutzen.
> 
> > Es gibt
> > auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
> > Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
> > steht, dass die Umstellung für jeden einzelnen Programmierer moderat
> > ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
> > emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
> > "TBD" ausgefüllt.
> Siehe oben.
> Aber es gibt in der Doku sehr viel Infomration, wie man PostgreSQL
> Server installiert, Datentypen, wie die Daten migriert werden,
> Einschränkungen, die Portierung von MDIDEMO, Konfiguartion, ...
> eigentlich alles. ... Aber ja, es gibt auch Lücken in der Doku.
> 
> > Ich würde es aktuell für äußerst problematisch halten, für die
> > angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
> > DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
> > so oder mal so benutzen kann.
> Verstehe ich nicht. Mach es wie im MDIDEMO gezeigt. Dann ist man für
> beide Welten (DBF und SQL) gerüstet und es ist nur eine Frage eines
> Define, wo die Daten herkommen.
> 
> Grüße,
> Frank
> 
> PS: So, jetzt muss ich nicht mehr dran denken.
> 
> PSPS: soeben ist ein neues Update erschienen (vor 10 Minuten), das
> sämtliche PGDBE PDRs behebt.
> 
> 
> 
> On 13.11.2015 10:00, Michael Papst wrote:
>> Hallo an alle,
>>
>> gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In
>> den Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt
>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>> "TBD" ausgefüllt.
>>
>> Ich würde es aktuell für äußerst problematisch halten, für die
>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>> so oder mal so benutzen kann.
>>
>> Vielleicht habe ich auch nur etwas übersehen?
>>
>> Gruß
>> PSP
> 
>

Hallo Michael,

und noch Mal danke.

Aber ich kann das nicht nachvollziehen. Und ich habe auch in die Runde 
gefragt und die Kollegen schütteln den Kopf. Das heißt, wir verstehen nicht.

1)
< In der Validierung ist die gleiche Anwendung in Xbase
 > 2.0 weit gekommen, so dass tatsächlich darüber nachgedacht wird,
< dem Kunden die Vorteile zukommen zu lassen, die nun möglich sind.
Jetzt erst? Warum? Meinst du damit eine 1:1 Umsetzung? Einfahc von 1.9 
mit der 2.0 kompiliert und gelinkt? Das muss einfach so gehen. Ohen 
drüber nachzudenken. Und zwar seit Anfang an. Nicht seit gestern.

2)
... oder sprichst du von der 2.0 Applikation mit Migration auf PDGBE?
Dein Szenario verstehen wir nicht. Leider. Kannst du uns das bitte an 
den Support schicken? Wenn es geht nich tnur Prosa, sondern in einem 
rekonstruierbaren Beispiel? Das wäre klasse.

 > Ich hoffe, dass die oben genannten Unzulänglichkeiten in naher Zukunft
 > ausgebessert werden.
Jein. Nur wenn es uns bekannt ist. Daher: bitte Beispiel!

Grüße,

Frank




On 16.05.2017 10:28, Michael Papst wrote:
> Hallo Frank,
>
> mittlerweile ist Xbase++ 2.0 weiter gediegen und gereift - aber noch immer im
> Detail unzureichend.
>
> Die Produktiv-Anwendung aus unserem Hause, die seit 1993 jeden Wandel
> mitgemacht hat, gibt es aktuell für die Kunden nur in Xbase 1.9 als
> Only-DBFNTX-Anwendung. In der Validierung ist die gleiche Anwendung in Xbase
> 2.0 weit gekommen, so dass tatsächlich darüber nachgedacht wird, dem Kunden
> die Vorteile zukommen zu lassen, die nun möglich sind.
>
> Jedoch ist auch ein Xbase 2.0-Pfad in der Testung, der auf PGDBE setzt,
> gegebebenenfalls DBFNTX nutzt, wenn es nötig ist. Der Upsize-Prozess konnte
> hinreichend automatisiert werden. Leider gibt es Probleme, dies intern zu
> über die Funktionen der dbfupsize.dll nutzen. Daher muss die dbfupsize.exe
> herhalten, was für eine einmalige Umstellung noch erträglich ist.
>
> Mit dem Build .785 ist DbPosition und DbGoPosition funktionsfähig zurück,
> wobei es Probleme mit Datenauswahlen basierend auf DbSetRelation bestehen, so
> dass beim Scrollen man irgendwo im Nichts landet. DbSetFilter wurde in Bezug
> auf PGDBE davor schon angefasst, arbeitet aber noch nicht zufriedenstellend,
> wenn die Filter-Bedinungen komplexer werden. Das führte dazu, dass man für
> die PGBDE an den wichtigen Stellen, eine permanent arbeitende Datenauswahl in
> den Hintergrund stellt, die aber am wichtigsten scheitert. Die
> WHERE-Bedingung im Select-Query beim use (cQuery) new wurde vollends
> ignoriert, so dass anstatt der gewünschten 30 oder 60 Datensätze alle geladen
> wurden. Technisch war das Query einwandfrei, da PGAdmin das gewünschte
> Ergebnis lieferte. Also ist man immer noch weit von einer Umsetzung entfernt.
> Manche Kunden fragen schon gar nicht mehr nach nativen SQL.
>
> Dass die Hilfe, egal ob englisch oder deutsch noch Lücken hat, dürfte ja
> weiterhin bekannt sein.
>
> Ich hoffe, dass die oben genannten Unzulänglichkeiten in naher Zukunft
> ausgebessert werden. Die Möglichkeiten lassen erahnen, wo es hingehen könnte.
> Aber bei den meisten fällt eine komplette Neuentwicklung aus finanziellen und
> zeitlichen Gründen einfach weg, dass man sie sofort nutzen könnte.
>
> Gruß
> Michael
>
>
> On 31.03.2017 15:00:51,  wrote:
>> Hallo Michael,
>>
>> ich ertappe mich, dass ich nun schon den ganzen Vormittag über diesen
>> Post nachdenke ... ist es nicht zu spät auf diesen Post zu antworten?
>>
>> Und gerade habe ich gedacht: nöh.
>>
>> Also, ich hoffe eigentlich, dass schon alles bekannt ist ...
>>
>> Was bedeutet sinnvolle Beispiele?
>> Ich versuche mal ein paar Anregungen zu geben.
>> Warum muss/soll es sinnvolle Beispiele geben? Ist das notwendig? Das ist
>> provokativ, aber ich gebe zu überlegen, dass die PGDBE ja nur der
>> Austausch des Datenspeicher (Storage) ist. Anstatt in DBF/CDX/NTX wird
>> eben in eine PostgreSQL Datenbank geschrieben und gelesen. Am Code muss
>> ich ja nichts ändern. Die dbSkip(), SKIP, GO BOTTOM, ... das Alles (dazu
>> sagt man auch ISAM Navigation) funktioniert wie vorher auch ... wie
>> gesagt, nur dass die Daten nun in der PostgreSQL Datenbank liegen.
>>
>> Man muss ja nicht zeigen, dass man eine Tabelle (unsere DBF) öffnen muss
>> und sortieren kann und suchen kann und dergleichen.
>>
>> Aber es gibt dennoch ein umfangreiches Beispiel, das die PGDBE dennoch
>> ganz gut zeigt: das MDI Beispiel (zu finden in
>> C:\Users\<user>\Documents\Xbase++\source\samples\apps\mdidemo)
>> kennt man ja. Viele haben es als Startpunkt genommen. Und genau dieses
>> Beipiel haben wir nach PDGBE portiert. Bitte lade das Projekt und suche
>> sämtliche Vorkommen von USE_POSTGRES. Das sind alle Stellen im Code, die
>> angepasst werden mussten, um mit der PostgreSQL Datenbank zu
>> funktionieren.
>>
>> Bitte ein Define USE_POSTGRES im code verwenden, neu compilieren (orher
>> die Daten auf die PostgreSQL Datenbank migireren) und laufen lassen. Das
>> war's.
>>
>> Also: ISAM auf einer SQL Datenbank. Keine Änderung des gewohnten
>> Programmierstils, aber die Sicherheit und Zuverlässigkeit eines SQL
>> Servers nutzen.
>>
>>> Es gibt
>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>> "TBD" ausgefüllt.
>> Siehe oben.
>> Aber es gibt in der Doku sehr viel Infomration, wie man PostgreSQL
>> Server installiert, Datentypen, wie die Daten migriert werden,
>> Einschränkungen, die Portierung von MDIDEMO, Konfiguartion, ...
>> eigentlich alles. ... Aber ja, es gibt auch Lücken in der Doku.
>>
>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>>> so oder mal so benutzen kann.
>> Verstehe ich nicht. Mach es wie im MDIDEMO gezeigt. Dann ist man für
>> beide Welten (DBF und SQL) gerüstet und es ist nur eine Frage eines
>> Define, wo die Daten herkommen.
>>
>> Grüße,
>> Frank
>>
>> PS: So, jetzt muss ich nicht mehr dran denken.
>>
>> PSPS: soeben ist ein neues Update erschienen (vor 10 Minuten), das
>> sämtliche PGDBE PDRs behebt.
>>
>>
>>
>> On 13.11.2015 10:00, Michael Papst wrote:
>>> Hallo an alle,
>>>
>>> gibt es überhaupt sinnvolle Beispiele für die Anwendung von PGDBE? In
>>> den Samples ist zwar was drin, aber nicht wirklich anwendbar. Es gibt
>>> auch kein Guide für die Umstellung von DBFNTX auf PGDBE - denn mit dem
>>> Upsize-Tool ist die Arbeit ja nicht getan. Zumal die Aussage im Raum
>>> steht, dass die Umstellung für jeden einzelnen Programmierer moderat
>>> ausfällt, in dem man die Verwendung der PGDBE in Anlehnung die DBFNTX
>>> emuliert. Aber davon sehe ich nichts und die Hilfe ist noch von viel
>>> "TBD" ausgefüllt.
>>>
>>> Ich würde es aktuell für äußerst problematisch halten, für die
>>> angedachte Parallel-Stellung der PGDBE zur DBFNTX die über 20 MB
>>> DacSqlStatementQuellcode alles doppelt zu programmieren, damit man mal
>>> so oder mal so benutzen kann.
>>>
>>> Vielleicht habe ich auch nur etwas übersehen?
>>>
>>> Gruß
>>> PSP
>>
>>
>

Am 19.05.2017 um 17:55 schrieb Frank Grossheinrich:
> Jetzt erst? Warum? Meinst du damit eine 1:1 Umsetzung? Einfahc von 1.9 
> mit der 2.0 kompiliert und gelinkt? Das muss einfach so gehen. Ohen 
> drüber nachzudenken. Und zwar seit Anfang an. Nicht seit gestern.

nun, dass das so gehen SOLLTE ist klar, wer sich darauf verläßt,
ohne die komplette Anwendung zu testen ist allerdings blauäugig 

Beispiele gefällig:

von der 1.90.xxx zur nächsten ich meine dem SL1 wurden Voreinstellungen 
geändert, sodass meine Controls erst nach dem überfahren mit der Maus 
sichtbar wurden. Groupbox() war nicht als parent sondern nur vorher 
aktiv. Da musste ich also den Code anpassen.

oder der PDR 6897 bei der Version 2.00.785:
Meine Anwendung die Millionen von Zeilen einliest (etwa 1000 pro 
Sekunde) trödelte plötzlich unter 10 pro Sekunde ...
zuerst dachte ich an Überhitzung ... dann an SSD Sterben ...
aber nein, das Testprogramm meiner Klasse war schnell wie immer.
Im XbaseForum dann die Lösung. Der XbpFileDialog() den ich IMMER schon 
zentriert aufgerufen habe, führt seit der Version 2.00.785 zu einem 
Problem mit dem CarbageCollector (oder wie der wieder heißt).
Für mein Programm, das intern die Strings zerlegt und in DBF speichert 
eine Katastrophe. Mit 1.90.355 alles OK.
Mit 2.00.785 und center auf .F. auch alles OK und sieht sogar besser 
aus. Warum diese kleine Systemeinstellung solche Nebenwirkungen hat, 
kann ich mir nicht erklären, muss ich ja auch nicht 

Lange Rede kurzer Sinn, alle Änderungen an allen Komponenten muss man 
eigentlich sauber neu durchtesten, leider machen das die wenigsten inkl. 
Microsoft - wobei hier wohl die testbare Menge einfach unüberschaubar 
geworden ist.

MfG
Hubert

Nicht zu vergessen auch die Kompatibilität mit Frax von 1.9 und 2.0

Am 13.06.2017 um 11:10 schrieb Hubert Brandel:
> Am 19.05.2017 um 17:55 schrieb Frank Grossheinrich:
>> Jetzt erst? Warum? Meinst du damit eine 1:1 Umsetzung? Einfahc von 1.9 
>> mit der 2.0 kompiliert und gelinkt? Das muss einfach so gehen. Ohen 
>> drüber nachzudenken. Und zwar seit Anfang an. Nicht seit gestern.
> 
> nun, dass das so gehen SOLLTE ist klar, wer sich darauf verläßt,
> ohne die komplette Anwendung zu testen ist allerdings blauäugig 
> 
> Beispiele gefällig:
> 
> von der 1.90.xxx zur nächsten ich meine dem SL1 wurden Voreinstellungen 
> geändert, sodass meine Controls erst nach dem überfahren mit der Maus 
> sichtbar wurden. Groupbox() war nicht als parent sondern nur vorher 
> aktiv. Da musste ich also den Code anpassen.
> 
> oder der PDR 6897 bei der Version 2.00.785:
> Meine Anwendung die Millionen von Zeilen einliest (etwa 1000 pro 
> Sekunde) trödelte plötzlich unter 10 pro Sekunde ...
> zuerst dachte ich an Überhitzung ... dann an SSD Sterben ...
> aber nein, das Testprogramm meiner Klasse war schnell wie immer.
> Im XbaseForum dann die Lösung. Der XbpFileDialog() den ich IMMER schon 
> zentriert aufgerufen habe, führt seit der Version 2.00.785 zu einem 
> Problem mit dem CarbageCollector (oder wie der wieder heißt).
> Für mein Programm, das intern die Strings zerlegt und in DBF speichert 
> eine Katastrophe. Mit 1.90.355 alles OK.
> Mit 2.00.785 und center auf .F. auch alles OK und sieht sogar besser 
> aus. Warum diese kleine Systemeinstellung solche Nebenwirkungen hat, 
> kann ich mir nicht erklären, muss ich ja auch nicht 
> 
> Lange Rede kurzer Sinn, alle Änderungen an allen Komponenten muss man 
> eigentlich sauber neu durchtesten, leider machen das die wenigsten inkl. 
> Microsoft - wobei hier wohl die testbare Menge einfach unüberschaubar 
> geworden ist.
> 
> MfG
> Hubert

Hubert,

und was wäre daraus die Konklusion? 1.9 forever?
Zwischen der 1.9 und dem heutigen Stand sind 382 PDRs behoben worden. 
Sind alle in der Dokumentation aufgeführt.

Und ja, wir haben in die 2.0 auch neue Fehler reingemacht. Aber 
definitiv keine 382. Und der XbpFileDialog() wird mit dem nächsten 
Update (kommt die Tage; wir testen schon felißig) behoben sein. Oder 
gehe einen Build zurück. Das ist doch das Schöne mit den Xbase++ Updates.

Plus, dass wir unsere Unit-Tests (das automatisierte Testen von 
Funktionen, Scenarios, Randbedingungen, ...) ständig erweitern. Das ist 
die derzeit am stärksten wachsende Codebasis. Wir testen. Und ich kann 
nur empfehlen, dass ihr auch eure Applikationen testet bevor sie an eure 
Kunden geht. Das traue ich mich schon fast nicht zu sagen, so 
solbstverständlich ist das.

Nun denn, danke für deine Rückmeldung

Frank


On 13.06.2017 11:10, Hubert Brandel wrote:
> Am 19.05.2017 um 17:55 schrieb Frank Grossheinrich:
>> Jetzt erst? Warum? Meinst du damit eine 1:1 Umsetzung? Einfahc von 1.9
>> mit der 2.0 kompiliert und gelinkt? Das muss einfach so gehen. Ohen
>> drüber nachzudenken. Und zwar seit Anfang an. Nicht seit gestern.
>
> nun, dass das so gehen SOLLTE ist klar, wer sich darauf verläßt,
> ohne die komplette Anwendung zu testen ist allerdings blauäugig 
>
> Beispiele gefällig:
>
> von der 1.90.xxx zur nächsten ich meine dem SL1 wurden Voreinstellungen
> geändert, sodass meine Controls erst nach dem überfahren mit der Maus
> sichtbar wurden. Groupbox() war nicht als parent sondern nur vorher
> aktiv. Da musste ich also den Code anpassen.
>
> oder der PDR 6897 bei der Version 2.00.785:
> Meine Anwendung die Millionen von Zeilen einliest (etwa 1000 pro
> Sekunde) trödelte plötzlich unter 10 pro Sekunde ...
> zuerst dachte ich an Überhitzung ... dann an SSD Sterben ...
> aber nein, das Testprogramm meiner Klasse war schnell wie immer.
> Im XbaseForum dann die Lösung. Der XbpFileDialog() den ich IMMER schon
> zentriert aufgerufen habe, führt seit der Version 2.00.785 zu einem
> Problem mit dem CarbageCollector (oder wie der wieder heißt).
> Für mein Programm, das intern die Strings zerlegt und in DBF speichert
> eine Katastrophe. Mit 1.90.355 alles OK.
> Mit 2.00.785 und center auf .F. auch alles OK und sieht sogar besser
> aus. Warum diese kleine Systemeinstellung solche Nebenwirkungen hat,
> kann ich mir nicht erklären, muss ich ja auch nicht 
>
> Lange Rede kurzer Sinn, alle Änderungen an allen Komponenten muss man
> eigentlich sauber neu durchtesten, leider machen das die wenigsten inkl.
> Microsoft - wobei hier wohl die testbare Menge einfach unüberschaubar
> geworden ist.
>
> MfG
> Hubert

Ich hatte nur deine Bemerkung kommentiert (so wie ich sie verstanden 
hatte), dass man bedenkenlos und ohne Tests umstellen kann.

Ich stimme vollkommen darin überein, dass es sinnvoll ist,
möglichst die neueste Version zu nutzen.
Mein Arbeitgeber hat ja für mich seit Jahren eine Prof. Sub.
im Dauer-ABO und ich gewöhne mich gerade an die Workbench,
die zwar ungewöhnt aber wirklich nützlich ist.

Tatsächlich hatte ich selbst bis zu dem FileDialog (der ja leicht zu 
umgehen war) keine Probleme.

Bedenkenlos: ja.
Ohne Test: NIE! Wie gesagt, wir schreiben uns die Finger wund für 
automatisierte Tests.



Workbench benutzen? KLASSE! Sehr gut. Ich will sie auch nicht mehr missen.

LG, Frank

On 04.07.2017 09:49, Hubert Brandel wrote:
> Ich hatte nur deine Bemerkung kommentiert (so wie ich sie verstanden
> hatte), dass man bedenkenlos und ohne Tests umstellen kann.
>
> Ich stimme vollkommen darin überein, dass es sinnvoll ist,
> möglichst die neueste Version zu nutzen.
> Mein Arbeitgeber hat ja für mich seit Jahren eine Prof. Sub.
> im Dauer-ABO und ich gewöhne mich gerade an die Workbench,
> die zwar ungewöhnt aber wirklich nützlich ist.
>
> Tatsächlich hatte ich selbst bis zu dem FileDialog (der ja leicht zu
> umgehen war) keine Probleme.
>
>