Nachdenken über neue WaWi/ABu für Kleinunternehmen

[Ekki Plicht]

Tag.

Ich hoffe ich bin hier einigermassen richtig.

Wir, eine mittelständische Fa. mit 20 Angestellten, sind dabei uns von
unserer bisherigen Software zu verabschieden. Bei der Suche nach einer
Lösung haben wir das Gefühl den Wald vor lauter Bäumen nicht zu sehen.
Deswegen suchen wir etwas Ideen von aussen.

Ist-Zustand
-----------
Selbstgeschriebene dBase-App, damit perfekt auf unsere Verhältnisse
zugeschnitten und schön schnell. Ca. 35Tsd Zeilen, ca. 30 verschiedene
Tabellen. Aber halt wenig ausbau- und zukunftsfähig, deswegen suchen wir
nach was Neuem.
Die Software macht die WaWi und Auftragsbuchhaltung mit dem Meisten was so
dazugehört. Natürlich sind viele Dinge sehr individuell auf unsere
Bedürfnisse zugeschnitten, z.B. beim Formulardruck für Lieferpapiere
verschiedener Versender, Datenschnittstelle zu verschiedenen Versendern,
Datenschnittstelle zum Webshop, aber auch an hundert anderen Stellen.

Soll-Zustand
------------
Funktionsumfang ist durch die verhandene SW gegeben, soll aber erweitert
werden um Funktionen die die SW heute nicht kann (Lagerverwaltung, Einkauf
uvm.). Nur neuer und etwas moderner.

Randbedingungen (soweit heute schon bekannt)
---------------
a) Source + Nutzungsrecht soll vorliegen, Wiederverkauf ist aber nicht
vorgesehen.
b) Auftragsvergabe ausser Haus - gerne, aber nicht auf Dauer. Letztendlich
wollen wir wieder in der Lage sein Anpassungen selber durchführen zu
können. Das soll über das schlichte Gestalten von Formularen hinausgehen.
c) Client-OS: Windows XP.
d) Server-OS: Windows 2003 Server (evtl. auch was unixoides).
e) Datenbank - noch nix entschieden.
f) ca. 12-20 Arbeitsplätze, ca. 8 Drucker
g) Pflichtenheft wird im Auftragsfall vorgelegt


Optionen wie wir Sie sehen
--------------------------
1) Standardsoftware kaufen. Nachdem wir nun durch die sehr individuellen
Anpassungen unserer eigenen Software verwöhnt sind, fürchten wir das uns
das nicht befriedigen wird. Kommt wohl nicht in Frage.

2) Standardpaket mit Anpassungen kaufen, Support vom freundlichen
Systemhaus um die Ecke. Hier gilt das gleiche wie bei 1), es sind zwar
Anpassungen möglich, aber die kosten natürlich immer heftig und dauern.

3) Komplett selber schreiben. Ja, ok, machbar, aber schon der Wahnsinn.
Muss ja nicht sein, auch wenn das die volle Flexibilität böte.

4) Vorhandenes Opensource Projekt nehmen und sich dranhängen, z.B. CAO. Da
könnte man am Entwicklungsprozess teilnehmen, eigene Entwicklungen
einfliessen lassen bzw. einen eigenen Fork bauen. Hohe Flexibilität und man
fängt nicht bei Null an.

War's das an Möglichkeiten? Wie würdet ihr an so ein Projekt rangehen? Hat
jemand uns was anzubieten? Dann bitte PM, Adresse ist replyfähig.


Gruß,
Ekki

[Heinrich Butschal]

Post by Ekki Plicht
Tag.
Ich hoffe ich bin hier einigermassen richtig.
Wir, eine mittelständische Fa. mit 20 Angestellten, sind dabei uns von
unserer bisherigen Software zu verabschieden. Bei der Suche nach einer
Lösung haben wir das Gefühl den Wald vor lauter Bäumen nicht zu sehen.
Deswegen suchen wir etwas Ideen von aussen.
Ist-Zustand
-----------
Selbstgeschriebene dBase-App, damit perfekt auf unsere Verhältnisse
zugeschnitten und schön schnell. Ca. 35Tsd Zeilen, ca. 30 verschiedene
Tabellen. Aber halt wenig ausbau- und zukunftsfähig, deswegen suchen wir
nach was Neuem.
Die Software macht die WaWi und Auftragsbuchhaltung mit dem Meisten was so
dazugehört. Natürlich sind viele Dinge sehr individuell auf unsere
Bedürfnisse zugeschnitten, z.B. beim Formulardruck für Lieferpapiere
verschiedener Versender, Datenschnittstelle zu verschiedenen Versendern,
Datenschnittstelle zum Webshop, aber auch an hundert anderen Stellen.
Soll-Zustand
------------
Funktionsumfang ist durch die verhandene SW gegeben, soll aber erweitert
werden um Funktionen die die SW heute nicht kann (Lagerverwaltung, Einkauf
uvm.). Nur neuer und etwas moderner.

Neuer und moderner soll doch wohl in erster Linie die GUI werden - oder?

Dann kann doch jemand sich damit beschäftigen die Module in z.B .Net zu
schreiben. Der Zugriff auf die vorhandenen Tabellen könnte doch bleiben?

Never touch a running ....

Oder benötigt Ihr transaktionfähige Datenbanken weil die User sich sonst die
Daten gegenseitig gleichzeitig überschrieben haben?

Dann ist eine Migration eigentlich des ganzen Systems fast unausweichlich.

Mit freundlichem Gruß,
Heinrich Butschal

[Olaf Müller]

Post by Heinrich Butschal
kann doch jemand sich damit beschäftigen die Module in z.B .Net zu
schreiben. Der Zugriff auf die vorhandenen Tabellen könnte doch bleiben?

.NET wäre auch meine Wahl.

Post by Heinrich Butschal
Never touch a running ....
Oder benötigt Ihr transaktionfähige Datenbanken weil die User sich sonst
die Daten gegenseitig gleichzeitig überschrieben haben?
Dann ist eine Migration eigentlich des ganzen Systems fast unausweichlich.

Sehe ich eher nicht so, das Importieren der vorhandenen Daten aus dem
alten System in eine relationale, moderne Datenbank, ist wohl das
geringste Problem - und sicher unaufwändiger, als den alten Datenbestand
ansprechen zu müssen.

Ganz ehrlich: wenn der Funktionsumfang so klar definiert werden kann,
man alles am Ist-Zustand messen kann, dann sollte eine Komplett-
Migration "relativ einfach" machbar sein.

Das ist aber nur meine persönliche (.NET-) Entwicklersicht, evtl
schadet es ja auch nicht, sich mal von SAP & Co. Angebote machen
zu lassen?

Grüße

[Lutz Schulze]

Post by Olaf Müller
Sehe ich eher nicht so, das Importieren der vorhandenen Daten aus dem
alten System in eine relationale, moderne Datenbank, ist wohl das
geringste Problem - und sicher unaufwändiger, als den alten Datenbestand
ansprechen zu müssen.

Es wird wohl eine Übergangszeit geben, in der aus beiden Systemen
zugegriffen werden muss. Schon weil das neue nie mit einem Schlag fertig
ist.

Post by Olaf Müller
Ganz ehrlich: wenn der Funktionsumfang so klar definiert werden kann,
man alles am Ist-Zustand messen kann, dann sollte eine Komplett-
Migration "relativ einfach" machbar sein.

Pfff. Da muss ich erstmal durchatmen. Hört man das nicht vorher immer?

Für ein Unternehmen ist das die Operation am offenen Herzen. Das will sehr
gut überlegt sein.

Lutz

[Matthias Kryn]

Post by Lutz Schulze

Post by Olaf Müller
Sehe ich eher nicht so, das Importieren der vorhandenen
Daten aus dem alten System in eine relationale, moderne
Datenbank, ist wohl das geringste Problem - und sicher
unaufwändiger, als den alten Datenbestand ansprechen zu
müssen.

Es wird wohl eine Übergangszeit geben, in der aus beiden
Systemen zugegriffen werden muss. Schon weil das neue nie mit
einem Schlag fertig ist.

ACK.

Post by Lutz Schulze

Post by Olaf Müller
Ganz ehrlich: wenn der Funktionsumfang so klar definiert
werden kann, man alles am Ist-Zustand messen kann, dann
sollte eine Komplett- Migration "relativ einfach" machbar
sein.

Pfff. Da muss ich erstmal durchatmen. Hört man das nicht
vorher immer?

Wenn ich Akquise mache, sage ich das auch :-P

Post by Lutz Schulze
Für ein Unternehmen ist das die Operation am offenen Herzen.
Das will sehr gut überlegt sein.

ACK.

Grüße
Matthias

[Olaf Müller]

Post by Lutz Schulze
Es wird wohl eine Übergangszeit geben, in der aus beiden Systemen
zugegriffen werden muss. Schon weil das neue nie mit einem Schlag fertig
ist.

Das ist kein Grund alte Leichen im Keller liegen zu lassen. Davon
abgesehen kann man zu einem bestimmten Zeitpunkt, wenn die neue
Saftware den Beta-Status verlässt, parallel arbeiten, und z.B.
neue oder einfach nur kleinere Aufträge mit dem neuen System
verwalten, kritische Abläufe noch mit dem alten erledigen. Sobald
sich die neue Lösung dann in der Praxis eingespielt hat, kann man
komplett die alte lahmlegen.

Post by Lutz Schulze

Post by Olaf Müller
Ganz ehrlich: wenn der Funktionsumfang so klar definiert werden kann,
man alles am Ist-Zustand messen kann, dann sollte eine Komplett-
Migration "relativ einfach" machbar sein.

Pfff. Da muss ich erstmal durchatmen. Hört man das nicht vorher immer?
Für ein Unternehmen ist das die Operation am offenen Herzen. Das will sehr
gut überlegt sein.

Auch hier: lieber ein Ende mit Schrecken, als Schrecken ohne Ende.
Es gibt immer Aspekte gegen so etwas, aber unterm Strich darf man
doch sagen: je länger Weiterentwicklungen bzw. sein sauberer
Schnitt hinausgezögert werden, desto schlimmer und verfahrener
wird die Situation irgendwann.

Gruß

[Aleks A.-Lessmann]

Post by Olaf Müller
Saftware den Beta-Status verlässt, parallel arbeiten, und z.B.
neue oder einfach nur kleinere Aufträge mit dem neuen System
verwalten, kritische Abläufe noch mit dem alten erledigen. Sobald
sich die neue Lösung dann in der Praxis eingespielt hat, kann man
komplett die alte lahmlegen.

Das willst du nicht. Bei solchen Lösungen sollte man einen Big Bang
Roll-out machen. Sonst hast du einen asynchronen Datenbestand, die
Mitarbeiter müssen in zwei Systeme nachschauen usw. usf. Unnötige
Mehrarbeit.

Es macht mehr Sinn, saubere und sehr gut durchgetestete Skripte zur
Übersetzung (und gfls Reparatur) der Daten zu haben, die man wenn nötig
wiederholt benutzen kann.

Schönen Gruß
Aleks

[Monsieur Ibrahim]

Post by Aleks A.-Lessmann

Post by Olaf Müller
Saftware den Beta-Status verlässt, parallel arbeiten, und z.B.
neue oder einfach nur kleinere Aufträge mit dem neuen System
verwalten, kritische Abläufe noch mit dem alten erledigen. Sobald
sich die neue Lösung dann in der Praxis eingespielt hat, kann man
komplett die alte lahmlegen.

Das willst du nicht. Bei solchen Lösungen sollte man einen Big Bang
Roll-out machen. Sonst hast du einen asynchronen Datenbestand, die
Mitarbeiter müssen in zwei Systeme nachschauen usw. usf. Unnötige
Mehrarbeit.

Ja, nach meiner Erfahrung ist es auch besser einen klaren Schnitt zu
machen, zB bietet sich dafür der Jahreswechsel an. D.h. bis dahin wird
mit dem alten System gearbeitet, ab zB 2008 _nur_ noch mit dem neuen
System. Das alte System läuft dann weiter als Archiv, also nur noch
_lesend_. Aus dem alten System werden in diesem Fall nur die Stammdaten
(Artikel, Kunden, Lieferanten etc) übernommen.

Gruß
Ibrahim

[Ekki Plicht]

Post by Lutz Schulze
Für ein Unternehmen ist das die Operation am offenen Herzen. Das will sehr
gut überlegt sein.

Genau darum geht's. Danke.

Gruß,
Ekki

[Lutz Schulze]

Post by Ekki Plicht
Genau darum geht's. Danke.

Ich hatte erst neulich Gelegenheit, mich von den reibungslosen Abläufen bei
euch zu überzeugen. Sonntags einen Icom-Empfänger bestellt, Dienstag brachte
ihn der Postbote. So wünscht man sich das als Kunde.

Lutz

[Heinrich Butschal]

Post by Olaf Müller

Post by Heinrich Butschal
kann doch jemand sich damit beschäftigen die Module in z.B .Net zu
schreiben. Der Zugriff auf die vorhandenen Tabellen könnte doch bleiben?

.NET wäre auch meine Wahl.

Post by Heinrich Butschal
Never touch a running ....
Oder benötigt Ihr transaktionfähige Datenbanken weil die User sich sonst
die Daten gegenseitig gleichzeitig überschrieben haben?
Dann ist eine Migration eigentlich des ganzen Systems fast unausweichlich.

Sehe ich eher nicht so, das Importieren der vorhandenen Daten aus dem
alten System in eine relationale, moderne Datenbank, ist wohl das
geringste Problem - und sicher unaufwändiger, als den alten Datenbestand
ansprechen zu müssen.

Die Datenmigration ist natürlich kein riesiger Aufwand, lediglich alle
Schnittstellen müssen dann angefasst werden. Dieser Aufwand kann erheblich sein.
Daher meine Frage ob es denn sei muss.

Mit freundlichem Gruß,
Heinrich Butschal

[Olaf Müller]

Post by Heinrich Butschal
Die Datenmigration ist natürlich kein riesiger Aufwand, lediglich alle
Schnittstellen müssen dann angefasst werden. Dieser Aufwand kann erheblich sein.
Daher meine Frage ob es denn sei muss.

Müssen tut man nur sterben. Ich kenne eure Anwendung nicht, weiß nicht
was da an welcher Ecke passiert. Aber für gewöhnlich sind Schnittstelle,
so sie denn eingesetzt werden und funktionieren, gut dokumentiert, und
damit auch "anzufassen".

Die Suche nach der Lösung mit dem geringsten Aufwand erscheint mir hier
der falsche Ansatz, wichtig ist die uneingeschränkte Zukunftsfähigkeit.

Gruß

[Heinrich Butschal]

Olaf Müller schrieb:
....

Post by Olaf Müller
Die Suche nach der Lösung mit dem geringsten Aufwand erscheint mir hier
der falsche Ansatz, wichtig ist die uneingeschränkte Zukunftsfähigkeit.

Zukunftsfähigkeit ist so ein Buzzword, schon allein weil wir alle nur im
Trüben fischen können, was die Zukunft bringen will.

Wenn der OP geschrieben hätte, die Datenbank ist schnarchlangsam und die
Datenkosistenz gerät immer wieder durcheinander, dann würde ich auch sofort
empfehlen alte Zöpfe abzuschneiden, aber dem scheint gerade nicht so zu sein.

Mit freundlichem Gruß,
Heinrich Butschal

[Olaf Mueller]

Post by Heinrich Butschal
Wenn der OP geschrieben hätte, die Datenbank ist schnarchlangsam und die
Datenkosistenz gerät immer wieder durcheinander, dann würde ich auch
sofort empfehlen alte Zöpfe abzuschneiden, aber dem scheint gerade nicht
so zu sein.

Naja, das ist aber nicht das einzige - und vor allem, wie man dem OP
entnehmen kann, nicht das wichtige Kriterium. Es geht vor allem um
Erweiterbarkeit, verfügbare Ressourcen, Dienstleister usw. Je länger
du den Zopf wachsen lässt, desto schwieriger wird es irgendwann, noch
schöne Strähnen einzufärben :-).

Mir ist hier ein krasses Beispiel vor Ort bekannt, wo vor Jahren
(> 10) begonnen wurde, eine riesige Datenbankanwendung mit Filemaker
zu entwickeln. Die Jahre gingen ins Land, die Technologie wurde immer
unbedeutender, und irgendwann kam es wie es kommen musste: man ging
im Streit mit dem Entwicklerteam auseinander. Ergebnis: es musste
jemand her, der das Projekt übernimmt. Suchergebnis im näheren
Umkreis (> 1 Mio Einwohner, Süddeutschland): so ziemlich genau 3
Firmen, die in Frage kommen.

Was das für eine wunderbare Situation ist, muss ich glaube ich nicht
beschreiben.

Deshalb sollte man so risikofreudig sein, den Schritt zu einer
Technologie mit Zukunft zu machen, und außer .NET fällt mir da
nur Java ein ...

Gruß

[Heinrich Butschal]

Olaf Mueller schrieb:
....

Post by Olaf Mueller
Deshalb sollte man so risikofreudig sein, den Schritt zu einer
Technologie mit Zukunft zu machen, und außer .NET fällt mir da
nur Java ein ...
Gruß

Gegen beides ist ja nichts einzuwenden. Nur beide können auch auf die alte
Datenbank zugreifen. Und so lange sie dieses tun, stören sie die bisherigen
Anwendungen nicht.

Mit freundlichem Gruß,
Heinrich Butschal

[Peter Fleischer]

Post by Heinrich Butschal
....

Post by Olaf Mueller
Deshalb sollte man so risikofreudig sein, den Schritt zu einer
Technologie mit Zukunft zu machen, und außer .NET fällt mir da
nur Java ein ...
Gruß

Gegen beides ist ja nichts einzuwenden. Nur beide können auch auf die
alte Datenbank zugreifen. Und so lange sie dieses tun, stören sie die
bisherigen Anwendungen nicht.

Hi Heinrich,
genau das würde ich auch empfehlen - DataLayer mit Interfaces, der vorerst
auf die dBase Dateien zugreifen (im .NET über den OleDb-Provider) und später
dann auf eine modernere Datenbank zugreifen. Da kann parallel weiter
gearbeitet werden und schrittweise Funktionen parallel arbeiten.

[Heinrich Butschal]

Post by Peter Fleischer

Post by Heinrich Butschal
....

Post by Olaf Mueller
Deshalb sollte man so risikofreudig sein, den Schritt zu einer
Technologie mit Zukunft zu machen, und außer .NET fällt mir da
nur Java ein ...
Gruß

Gegen beides ist ja nichts einzuwenden. Nur beide können auch auf die
alte Datenbank zugreifen. Und so lange sie dieses tun, stören sie die
bisherigen Anwendungen nicht.

Hi Heinrich,
genau das würde ich auch empfehlen - DataLayer mit Interfaces, der vorerst
auf die dBase Dateien zugreifen (im .NET über den OleDb-Provider) und später
dann auf eine modernere Datenbank zugreifen. Da kann parallel weiter
gearbeitet werden und schrittweise Funktionen parallel arbeiten.

Auch diese Vorgehensweise ist sinnvoll. In der Übergangszeit kann durchaus per
cronjob die neue Datenbank die Daten der alten Datenbank ziehen. Bis man auf
die alte dbase verzichten kann.

Mit freundlichem Gruß,
Heinrich Butschal

[Ekki Plicht]

Post by Heinrich Butschal
....

Post by Olaf Müller
Die Suche nach der Lösung mit dem geringsten Aufwand erscheint mir hier
der falsche Ansatz, wichtig ist die uneingeschränkte Zukunftsfähigkeit.

Zukunftsfähigkeit ist so ein Buzzword, schon allein weil wir alle nur im
Trüben fischen können, was die Zukunft bringen will.

Auch wahr, aber Du schreibst es selbst - die Glaskugeln sind alle trübe.

Post by Heinrich Butschal
Wenn der OP geschrieben hätte, die Datenbank ist schnarchlangsam und die
Datenkosistenz gerät immer wieder durcheinander, dann würde ich auch sofort
empfehlen alte Zöpfe abzuschneiden, aber dem scheint gerade nicht so zu sein.

Nicht schnarchlangsam, aber die Konsistenz gerät so 1x die Woche in Gefahr,
dann ist eine Reorganisation angesagt. Das ist mit ein Grund da in den
nächsten Monaten was tun zu müssen.

Danke & Gruß,
Ekki

[Ekki Plicht]

Post by Olaf Müller

Post by Heinrich Butschal
Die Datenmigration ist natürlich kein riesiger Aufwand, lediglich alle
Schnittstellen müssen dann angefasst werden. Dieser Aufwand kann erheblich sein.
Daher meine Frage ob es denn sei muss.

Müssen tut man nur sterben. Ich kenne eure Anwendung nicht, weiß nicht
was da an welcher Ecke passiert. Aber für gewöhnlich sind Schnittstelle,
so sie denn eingesetzt werden und funktionieren, gut dokumentiert, und
damit auch "anzufassen".

Gut dokumentiert ist das hier nicht. 1 Programmierer, der nur für sich und
uns programmiert (bisher). <ironie> Da braucht man nichts zu
dokumentieren... </ironie>

Post by Olaf Müller
Die Suche nach der Lösung mit dem geringsten Aufwand erscheint mir hier
der falsche Ansatz, wichtig ist die uneingeschränkte Zukunftsfähigkeit.

Ok,

Danke & Gruß,
Ekki

[Ekki Plicht]

Post by Olaf Müller

Post by Heinrich Butschal
kann doch jemand sich damit beschäftigen die Module in z.B .Net zu
schreiben. Der Zugriff auf die vorhandenen Tabellen könnte doch bleiben?

.NET wäre auch meine Wahl.

Ok, kannst Du mir den Grund dafür in für Dich angemessener Zeit erläutern?
Ich weiss von .NET genau soviel das es existiert...

Post by Olaf Müller

Post by Heinrich Butschal
Never touch a running ....
Oder benötigt Ihr transaktionfähige Datenbanken weil die User sich sonst
die Daten gegenseitig gleichzeitig überschrieben haben?
Dann ist eine Migration eigentlich des ganzen Systems fast unausweichlich.

Sehe ich eher nicht so, das Importieren der vorhandenen Daten aus dem
alten System in eine relationale, moderne Datenbank, ist wohl das
geringste Problem - und sicher unaufwändiger, als den alten Datenbestand
ansprechen zu müssen.

100% ACK.

Post by Olaf Müller
Ganz ehrlich: wenn der Funktionsumfang so klar definiert werden kann,
man alles am Ist-Zustand messen kann, dann sollte eine Komplett-
Migration "relativ einfach" machbar sein.

Ja, da ist das Problem. Das Ganze erscheint mir auch "relativ einfach".
Aber ich habe schon zuviele Pferde kotzen sehen und nehme meine erste
Aufwandsschätzung heute immer mal 2.5. Was hier auf Unglauben stösst. Am
Ende habe ich dann aber doch recht.

Post by Olaf Müller
Das ist aber nur meine persönliche (.NET-) Entwicklersicht, evtl
schadet es ja auch nicht, sich mal von SAP & Co. Angebote machen
zu lassen?

Ich habe in meinem leben eine Migration zu SAP in $GANZGROSSEFIRMA gemacht
und glaube nicht das ich das nochmal haben möchte. Aber ok, angucken kann
man sich das ja mal.

Danke & Gruß,
Ekki

[Matthias Kryn]

Post by Ekki Plicht

Post by Olaf Müller
Ganz ehrlich: wenn der Funktionsumfang so klar definiert
werden kann, man alles am Ist-Zustand messen kann, dann
sollte eine Komplett-Migration "relativ einfach" machbar
sein.

Ja, da ist das Problem. Das Ganze erscheint mir auch "relativ
einfach".
Aber ich habe schon zuviele Pferde kotzen sehen und nehme
meine erste Aufwandsschätzung heute immer mal 2.5. Was hier
auf Unglauben stösst. Am Ende habe ich dann aber doch recht.

Wenn ich auf meine Erfahrungswerte zurückblicke: wenn das
Pflichten-/Lastenheft nicht bis aufs I-Tüpfelchen ausgearbeitet
ist, kann ich Deinen Faktor nachvollziehen.

Grüße
Matthias

[Peter Fleischer]

Post by Ekki Plicht

Post by Olaf Müller
Sehe ich eher nicht so, das Importieren der vorhandenen Daten aus dem
alten System in eine relationale, moderne Datenbank, ist wohl das
geringste Problem - und sicher unaufwändiger, als den alten
Datenbestand ansprechen zu müssen.

100% ACK.

Mit VB.NET kann man mit einem einfach zu erstellenden DataLayer
(Zwischenschicht) problemlos auf die dBase-Dateien zugreifen und dann
umschalten, wenn alle Funktionen in .NET laufen.

Post by Ekki Plicht

Post by Olaf Müller
Ganz ehrlich: wenn der Funktionsumfang so klar definiert werden kann,
man alles am Ist-Zustand messen kann, dann sollte eine Komplett-
Migration "relativ einfach" machbar sein.

Ja, da ist das Problem. Das Ganze erscheint mir auch "relativ
einfach". Aber ich habe schon zuviele Pferde kotzen sehen und nehme
meine erste Aufwandsschätzung heute immer mal 2.5. Was hier auf
Unglauben stösst. Am Ende habe ich dann aber doch recht.

Das Hauptproblem bei solcher Migration ist nicht die 1:1-Umsetzung der alten
Bedientechnologie, sondern die Wünsche, mit der Umstellung ein Vielzahl von
bisher nicht gelösten Aufgaben in Zukunft zu unterstützen, was meist
Korreturen in der Ablauforganisation und in der Struktur der Datenbank
erfordern.

Post by Ekki Plicht

Post by Olaf Müller
Das ist aber nur meine persönliche (.NET-) Entwicklersicht, evtl
schadet es ja auch nicht, sich mal von SAP & Co. Angebote machen
zu lassen?

Ich habe in meinem leben eine Migration zu SAP in $GANZGROSSEFIRMA
gemacht und glaube nicht das ich das nochmal haben möchte. Aber ok,
angucken kann man sich das ja mal.

Bei SAP hast du den Porsche unter den System mit dem Nachteil, dass auch
eine gehörige Portion Ablauforganisation an das System SAP anzupassen ist.

[Martin Schoenbeck]

Hallo Ekki,

Post by Ekki Plicht
Ja, da ist das Problem. Das Ganze erscheint mir auch "relativ einfach".
Aber ich habe schon zuviele Pferde kotzen sehen und nehme meine erste
Aufwandsschätzung heute immer mal 2.5. Was hier auf Unglauben stösst. Am
Ende habe ich dann aber doch recht.

Normalerweise sollte man noch zusätzlich die nächstgrößere Einheit nehmen.
Dafür reicht dann ansonsten der Faktor 2.

Gruß Martin

[Ekki Plicht]

Post by Heinrich Butschal
Neuer und moderner soll doch wohl in erster Linie die GUI werden - oder?

Ja, und weg von DOS(!). Wir bekommen bald keine Hardware mehr dafür ;.)

Post by Heinrich Butschal
Dann kann doch jemand sich damit beschäftigen die Module in z.B .Net zu
schreiben. Der Zugriff auf die vorhandenen Tabellen könnte doch bleiben?

.Net ok, vorhandene Tabellen liegen im .dbf/.mdx Format vor und ich glaube
kaum das wir die behalten wollen/sollten. Es gibt in der Tat gelegentlich
Zugriffsfehler, da kommt der Index durcheinander. Der drohende Aufwand
_den_ Fehler zu finden lässt eine Migration zu einem komplett neuen System
kleiner erscheinen.
Es soll ein zentraler Server mit MySql, postgres o.ä. eingesetzt werden.

Post by Heinrich Butschal
Never touch a running ....

Ok, bei zunehmend kleiner werdenden Werten von 'running' steigt der
Leidensdruck dann doch. Ich frag hier ja nicht aus Spaß :-)

Post by Heinrich Butschal
Oder benötigt Ihr transaktionfähige Datenbanken weil die User sich sonst die
Daten gegenseitig gleichzeitig überschrieben haben?

Ja, s.o.

Post by Heinrich Butschal
Dann ist eine Migration eigentlich des ganzen Systems fast unausweichlich.

Eben. Es geht jetzt 'nur noch' um den schmerzfreiesten Weg dorthin.

Danke & Gruß,
Ekki

[Peter Fleischer]

Post by Ekki Plicht

Post by Heinrich Butschal
Dann kann doch jemand sich damit beschäftigen die Module in z.B .Net
zu schreiben. Der Zugriff auf die vorhandenen Tabellen könnte doch
bleiben?

.Net ok, vorhandene Tabellen liegen im .dbf/.mdx Format vor und ich
glaube kaum das wir die behalten wollen/sollten.

Hi Ekki,
die Übergangszeit beträgt nicht ein Wochenende. Deshalb sollte die neue
Lösung unbedingt vorerst auf den alten Datenbestnd zugreifen. Das ist mit
.NET problemlos möglich.

Post by Ekki Plicht
Es gibt in der Tat
gelegentlich Zugriffsfehler, da kommt der Index durcheinander. Der
drohende Aufwand _den_ Fehler zu finden lässt eine Migration zu einem
komplett neuen System kleiner erscheinen.

Unterschätz den Umstellungsaufwand nicht:-)

Post by Ekki Plicht
Es soll ein zentraler Server mit MySql, postgres o.ä. eingesetzt werden.

Ich würde keines dieser Spielzeuge einsetzen. Die Großen (MS SQL Server,
Oracle, DB2 von IBM) haben kostenlose abgespeckte Versionen, der
Einschränkungen bedeutungslos sind und einen vielfachen Leistungsumfang
gegenüber textbasierten serverlosen Anwednungen haben.

Post by Ekki Plicht

Post by Heinrich Butschal
Never touch a running ....

Ok, bei zunehmend kleiner werdenden Werten von 'running' steigt der
Leidensdruck dann doch. Ich frag hier ja nicht aus Spaß :-)

Man kann ja bei der Umstellung beim größten Leidensdruck anfangen.

Post by Ekki Plicht

Post by Heinrich Butschal
Oder benötigt Ihr transaktionfähige Datenbanken weil die User sich
sonst die Daten gegenseitig gleichzeitig überschrieben haben?

Ja, s.o.

Das können alle Großen auch in den kostenlosen Versionen.

Post by Ekki Plicht

Post by Heinrich Butschal
Dann ist eine Migration eigentlich des ganzen Systems fast
unausweichlich.

Eben. Es geht jetzt 'nur noch' um den schmerzfreiesten Weg dorthin.

schnerzfrei ist wirklich sehr optimistisch :-)

[Lutz Schulze]

Post by Peter Fleischer
Ich würde keines dieser Spielzeuge einsetzen. Die Großen (MS SQL Server,
Oracle, DB2 von IBM) haben kostenlose abgespeckte Versionen, der
Einschränkungen bedeutungslos sind und einen vielfachen Leistungsumfang
gegenüber textbasierten serverlosen Anwednungen haben.

Hier zwar OT, aber damit meinst du jetzt nicht MySQL oder postgres usw.?

Post by Peter Fleischer
schnerzfrei ...

Das lasse ich mal so stehen ;-) Würde ich auch jedem Kunden versichern.

Lutz

--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren

[Peter Fleischer]

Post by Lutz Schulze

Post by Peter Fleischer
Ich würde keines dieser Spielzeuge einsetzen. Die Großen (MS SQL
Server, Oracle, DB2 von IBM) haben kostenlose abgespeckte Versionen,
der Einschränkungen bedeutungslos sind und einen vielfachen
Leistungsumfang gegenüber textbasierten serverlosen Anwednungen
haben.

Hier zwar OT, aber damit meinst du jetzt nicht MySQL oder postgres usw.?

Hi Lutz,
ich meinte mit "textbasierte serverlose Anwendungen" die jetzige Lösung mit
dBase.

[Lutz Schulze]

Post by Peter Fleischer

Post by Lutz Schulze

Post by Peter Fleischer
Ich würde keines dieser Spielzeuge einsetzen. Die Großen (MS SQL
Server, Oracle, DB2 von IBM) haben kostenlose abgespeckte Versionen,
der Einschränkungen bedeutungslos sind und einen vielfachen
Leistungsumfang gegenüber textbasierten serverlosen Anwednungen
haben.

Hier zwar OT, aber damit meinst du jetzt nicht MySQL oder postgres usw.?

Hi Lutz,
ich meinte mit "textbasierte serverlose Anwendungen" die jetzige Lösung mit
dBase.

Gut, das hat nun wahrscheinlich wirklich die besten Tage hinter sich . Aber
die anderen beiden als Spielzeuge zu bezeichnen ...

Lutz

[Hans- Peter Walther]

Post by Peter Fleischer
Hi Ekki,
die Übergangszeit beträgt nicht ein Wochenende. Deshalb sollte
die neue Lösung unbedingt vorerst auf den alten Datenbestnd
zugreifen. Das ist mit .NET problemlos möglich.

Ich hätte da "unter anderem" geschrieben. Oder ist hier eine
Akquise- Gruppe?

Post by Peter Fleischer

Post by Ekki Plicht
Es soll ein zentraler Server mit MySql, postgres o.ä.
eingesetzt werden.

Ich würde keines dieser Spielzeuge einsetzen. Die Großen (MS
SQL Server, Oracle, DB2 von IBM) haben kostenlose abgespeckte

Postgres ein Spielzeug? Das zeigt mir endgültig, das du entweder
*sehr* einseitig ausgerichtet bist, oder außer Schlagworten
keine Ahnung hast.

Tststs.
mfg
HPW

[Peter Fleischer]

Post by Hans- Peter Walther
Postgres ein Spielzeug? Das zeigt mir endgültig, das du entweder
*sehr* einseitig ausgerichtet bist, oder außer Schlagworten
keine Ahnung hast.

Hi Hans-Peter,
mag sein, dass ich etwas einseitig ausgerichtet bin, da ich es meist mit
Partnern zu tun habe, die hohe Forderungen haben und in der Vergangenheit
mit den Möglichkeiten von PostgresSQL nicht zufrieden waren. Ob sich das in
Zukunft mal ändert, kann ich jetzt nicht sagen.

Ich will hier niemanden überzeugen oder auch Aquise machen :-)

[Michael Trowe]

Post by Peter Fleischer
mag sein, dass ich etwas einseitig ausgerichtet bin, da ich es meist mit
Partnern zu tun habe, die hohe Forderungen haben und in der Vergangenheit
mit den Möglichkeiten von PostgresSQL nicht zufrieden waren. Ob sich das in
Zukunft mal ändert, kann ich jetzt nicht sagen.

Typisches Phänomen gerade bei Datenbanken: Die werden meistens nach den
Skills der Entwickler ausgesucht und nicht nach den Anforderungen der
Anwendung.
Und je nach Aufgabenstellung kann selbst ein Oracle nicht zwingend gegen
Postgres, Firebird oder MySQL konkurrierern.
Und man glaubt es kaum: Einige der OpenSource Lösungen wurden schon in
freier Wildbahn in wirklich kritischen Anwendungen z.Bsp. in Börsen
gesichtet.

Gruß
Michael

[Matthias Frey]

Post by Michael Trowe
Typisches Phänomen gerade bei Datenbanken: Die werden meistens nach den
Skills der Entwickler ausgesucht und nicht nach den Anforderungen der
Anwendung.

Finde ich nicht mal so schlecht. Der Auftraggeber braucht schließlich
in erster Linie keine Datenbank, sondern eine Lösung.
Und da halte ich die Skills der Entwickler für wichtiger.

Und so speziell^w ungewöhnlich sind die Anforderungen hier ja wohl auch nicht.

Post by Michael Trowe
Gruß
Michael

Grüße
Matthias

[Michael Trowe]

Post by Matthias Frey
Finde ich nicht mal so schlecht. Der Auftraggeber braucht schließlich
in erster Linie keine Datenbank, sondern eine Lösung.
Und da halte ich die Skills der Entwickler für wichtiger.
Und so speziell^w ungewöhnlich sind die Anforderungen hier ja wohl auch nicht.

Was die Anforderungen in diesem Fall angeht, geb ich Dir recht: Eigentlich
eine Aufgabe die (fast) jede DB meistern sollte.
Aber etwas allgemeiner betrachtet, sind die Unterschiede zwischen den
Systemen so groß, daß ich denke, die DB sollte schon sehr sorgfältig nach
den Anforderungen der Anwendung ausgesucht werden. Um mal son paar
Stichwörter in den Raum zu werfen, bei denen es doch erhebliche
Unterschiede gibt: Transaktionen, Volltext-Suche, Externe-Erweiterbarkeit,
Authentifizierung etc.
Und IMHO ist die DB die Anwendung - oder macht zumindest deutlich mehr als
50% davon aus. Oder ist eben in vielen Fällen auch leider der Flaschenhals,
der hätte vermieden werden können, wenn das DB-System mit mehr Sorgfalt
ausgewählt worden wäre.

Gruß,
Michael

[Aleks A.-Lessmann]

Post by Peter Fleischer

Post by Hans- Peter Walther
Postgres ein Spielzeug? Das zeigt mir endgültig, das du entweder
*sehr* einseitig ausgerichtet bist, oder außer Schlagworten
keine Ahnung hast.

mit den Möglichkeiten von PostgresSQL nicht zufrieden waren. Ob sich das in

Mit PostGre habe ich keine Erfahrung gesammelt. Ich kann aber aus
eigener Erfahrung in Projekten sagen , dass MySQL i.S. Hochverfügbarkeit
und Geschwindigkeit problemlos an Oracle et al. rankommt.

Und bevor jemand fragt:
Adressenverwaltung in großem Logistik Unternehmen
2x Bereitstellung von IP Daten in RADIUS Server zweier Telcos.
Antwortzeiten unter 2ms als QoS Parameter

Da sollte eine Anwendung für 20 Personen keine Probleme machen...
Aleks

[Peter Fleischer]

Post by Aleks A.-Lessmann
...
Mit PostGre habe ich keine Erfahrung gesammelt. Ich kann aber aus
eigener Erfahrung in Projekten sagen , dass MySQL i.S.
Hochverfügbarkeit und Geschwindigkeit problemlos an Oracle et al.
rankommt.

Hi Aleks,
bezüglich Verfügbarkeit gibt es bei passender Ausstattung keine
Unterschiede. Aber bezüglich Geschwindigkeit kann es gravierende
Unterschiede geben, wenn skalierbare Anwendungen erstellt werden, da MySQL
über keine CLR-Integration verfügt und diese Funktionen deshalb in die
Client-Anwednung auszulagern sind.

Post by Aleks A.-Lessmann
Adressenverwaltung in großem Logistik Unternehmen
2x Bereitstellung von IP Daten in RADIUS Server zweier Telcos.
Antwortzeiten unter 2ms als QoS Parameter
Da sollte eine Anwendung für 20 Personen keine Probleme machen...

Wenn die Anforderungen passen, dann natürlich.

[Lutz Schulze]

Post by Peter Fleischer

Post by Aleks A.-Lessmann
...
Mit PostGre habe ich keine Erfahrung gesammelt. Ich kann aber aus
eigener Erfahrung in Projekten sagen , dass MySQL i.S.
Hochverfügbarkeit und Geschwindigkeit problemlos an Oracle et al.
rankommt.

Hi Aleks,
bezüglich Verfügbarkeit gibt es bei passender Ausstattung keine
Unterschiede. Aber bezüglich Geschwindigkeit kann es gravierende
Unterschiede geben, wenn skalierbare Anwendungen erstellt werden, da MySQL
über keine CLR-Integration verfügt und diese Funktionen deshalb in die
Client-Anwednung auszulagern sind.

Ich frage mal als Laie: wären Stored Procedures da nicht eine allgemeinere
Lösung, die auch auf Nicht-MS Servern funktionieren würde?

Wenn man etwas neu macht, dann doch nicht gleich wieder mit
Herstellerbindung, oder haben mittlerweile auch andere CLR in die
Datenbankserver integriert?

Lutz

[Peter Fleischer]

Post by Lutz Schulze
...
Ich frage mal als Laie: wären Stored Procedures da nicht eine
allgemeinere Lösung, die auch auf Nicht-MS Servern funktionieren
würde?

Hi Lutz,
eine MS Server und ein Datenbankserver sind zwei unterschiedliche Dinge. Auf
einem MS Server kann ein Datenbankserver laufen, genau wie auch auf einem
Nicht-MS Server.

Eine Stored Procedure (SP) ist eine im Datenbankserver gespeicherte Folge
von SQL-Anweisungen. Wenn der Datenbankserver das unterstützt, dann ist das
unabhängig vom genutzten Server, unter dessen Steuerung der Datenbankserver
läuft. Mit SP's kann man eine Vielzahl von Problemen lösen und die Lösung
kann für den konkreten Anwendungsfall ausreichend sein. In einer
Mehrnutzerumgebung, bei starker Abhängigkeit einzelner Orgabläufe und bei
"dünnen" Datenleitungen (z.B. mobile Außendienstmitarbeiter) kann die
Verlagerung von Abläufen in den Datenbankserver sinnvoll werden. Und da
stoßen SP's an ihre Grenzen und zusätzliche im Datenbankserver verfügbare
selbst erstellte Methoden können solche Prozesse vereinfachen und
beschleunigen.

Post by Lutz Schulze
Wenn man etwas neu macht, dann doch nicht gleich wieder mit
Herstellerbindung, oder haben mittlerweile auch andere CLR in die
Datenbankserver integriert?

Mit der Nutzung von SQL bindest du dich aber an Hersteller, die das
untertützen, genau wie bei der Nutzung von dBase. Wo siehst du da Probleme?
Bei der Nutzung der CLR bindest du dich genau so an die Datenbankserver, die
das unterstützen. Viele Lösungen kann man auch für den Kunden ausreichend
effektiv ohne moderne Technologien lösen, z.B. auch mit dBase. Aber
irgendwann kommen Forderungen, für die man ggf. auf moderne Technologien
umsteigen sollte, um sowohl in der Entwicklung als auch in der Nutzung für
den Kunden effektive Lösungen bereitzustellen. Ohne eine ausreichende
Analyse und Vorbereitung kann man sowieso nur allgemeine Meinungen äußern.
Letztendlich muss der Kunde beraten werden und Vertrauen haben, dass der
Berater ihm eine vertrauenswürdige Lösung vorschlägt. Und wenn der Berater
der Meinung ist, dass modernere Technologien für den Kunden bedeutungslos
sind und es aber kostengünstige Realisierungen mit anderen Technologien
gibt, warum soll der Kunde bei ausreichendem Vertrauen nicht auch eine
solche Lösung effektiv nutzen können.

[Lutz Schulze]

Post by Peter Fleischer

Post by Lutz Schulze
Ich frage mal als Laie: wären Stored Procedures da nicht eine
allgemeinere Lösung, die auch auf Nicht-MS Servern funktionieren
würde?

Hi Lutz,
eine MS Server und ein Datenbankserver sind zwei unterschiedliche Dinge. Auf
einem MS Server kann ein Datenbankserver laufen, genau wie auch auf einem
Nicht-MS Server.

Ich meinte mit MS Server in dem Kontext natürlich einen MS-SQL Server.

Post by Peter Fleischer
Eine Stored Procedure (SP) ist eine im Datenbankserver gespeicherte Folge
von SQL-Anweisungen. Wenn der Datenbankserver das unterstützt, dann ist das
unabhängig vom genutzten Server, unter dessen Steuerung der Datenbankserver
läuft. Mit SP's kann man eine Vielzahl von Problemen lösen und die Lösung
kann für den konkreten Anwendungsfall ausreichend sein. In einer
Mehrnutzerumgebung, bei starker Abhängigkeit einzelner Orgabläufe und bei
"dünnen" Datenleitungen (z.B. mobile Außendienstmitarbeiter) kann die
Verlagerung von Abläufen in den Datenbankserver sinnvoll werden. Und da
stoßen SP's an ihre Grenzen und zusätzliche im Datenbankserver verfügbare
selbst erstellte Methoden können solche Prozesse vereinfachen und
beschleunigen.

Post by Lutz Schulze
Wenn man etwas neu macht, dann doch nicht gleich wieder mit
Herstellerbindung, oder haben mittlerweile auch andere CLR in die
Datenbankserver integriert?

Mit der Nutzung von SQL bindest du dich aber an Hersteller, die das
untertützen, genau wie bei der Nutzung von dBase. Wo siehst du da Probleme?
Bei der Nutzung der CLR bindest du dich genau so an die Datenbankserver, die
das unterstützen.

Ähm, wieviele Hersteller ünterstützen SQL und wieviele Hersteller
unterstützen dagegen die CLR auf dem Datenbankserver?
Seit wann gibt es die CLR? Wieso soll die jetzt besonders zukunftssicher
sein? Sollte das nicht mit Java auch schon mal alles ganz super werden?

Post by Peter Fleischer
Viele Lösungen kann man auch für den Kunden ausreichend
effektiv ohne moderne Technologien lösen, z.B. auch mit dBase. Aber
irgendwann kommen Forderungen, für die man ggf. auf moderne Technologien
umsteigen sollte, ...

Auf eine mit _einem_ Hersteller? Ich weiss nicht. Vielleicht auf dem Client,
aber doch nicht für die wichtigen Funktionen auf dem DB-Server. Die würde
ich doch so auslegen, dass ich da mal ohne Probleme auf ein anderes Produkt
wechseln kann.

Lutz

[Peter Fleischer]

Post by Lutz Schulze
Ich meinte mit MS Server in dem Kontext natürlich einen MS-SQL Server.

Hi Lutz,
es gibt aber auch noch andere Datenbankserver. Warum versteifst du dich auf
den SQL Server von microsoft? Oracle und DB2 sind in einigen Belangen besser
und Oracle XE ist auch noch kostenlos und läuft auch auf anderen
Betreibssystemen.

Post by Lutz Schulze
...
Ähm, wieviele Hersteller ünterstützen SQL und wieviele Hersteller
unterstützen dagegen die CLR auf dem Datenbankserver?

Bei neuen Texhnoligien beginnen immer erst mal nur wenige. CLR unterstützen
z.B. MS SQL Server 2005 in allen Versionen, Oracle 10g und DB2.

Post by Lutz Schulze
Seit wann gibt es die CLR?

Seit ca. 4 Jahren und in den Datenbankservern freigegeben seit ca. 1,5
Jahren.

Post by Lutz Schulze
Wieso soll die jetzt besonders
zukunftssicher sein?

Auch wenn du nicht an eine Zukunftsischerheit glaubst, so sind die für die
Arbeit im Datenbankserver gekapselten Funktionalitäten auch außerhalb
anwendbar, falls es nach Beendung des Supports für diese Datenbankserver in
schätzungsweise 10 Jahren keine nachfolgende Unterstützung mehr gibt. Da
aber die Entwickler der genannten 3 Datenbankserver jeweils anstreben, die
Marktführerschaft zu erringen, ist es recht unwahrscheinlich, dass sie
solche Features einfach nicht weiter unterstützen werden.

Post by Lutz Schulze
Sollte das nicht mit Java auch schon mal alles
ganz super werden?

Vielleicht wird es noch. CLR-Unterstützung ist aber Realität.

Post by Lutz Schulze

Post by Peter Fleischer
Viele Lösungen kann man auch für den Kunden ausreichend
effektiv ohne moderne Technologien lösen, z.B. auch mit dBase. Aber
irgendwann kommen Forderungen, für die man ggf. auf moderne
Technologien umsteigen sollte, ...

Auf eine mit _einem_ Hersteller?

Warum willst du unbedingt eine Lösung, die nur ein Hersteller bereitstellt?
Ich verstehe deine Diskussion nicht.

Post by Lutz Schulze
Ich weiss nicht. Vielleicht auf dem
Client, aber doch nicht für die wichtigen Funktionen auf dem
DB-Server.

Deshalb ja mein Vorschlag, auch moderne Technologien in die Betrachtung
einbeziehen, die heute schon von mehreren Herstellern angeboten werden.

Post by Lutz Schulze
Die würde ich doch so auslegen, dass ich da mal ohne
Probleme auf ein anderes Produkt wechseln kann.

Kannst du doch heute schon. Du musst es nur bei der Konzipierung vorsehen,
um nicht allzu sehr spezifische SQL Dialekte zu nutzen.

[Lutz Schulze]

Post by Peter Fleischer

Post by Lutz Schulze
Ich meinte mit MS Server in dem Kontext natürlich einen MS-SQL Server.

Hi Lutz,
es gibt aber auch noch andere Datenbankserver. Warum versteifst du dich auf
den SQL Server von microsoft? Oracle und DB2 sind in einigen Belangen besser
und Oracle XE ist auch noch kostenlos und läuft auch auf anderen
Betreibssystemen.

Ich war der Meinung, dass die CLR Funktionen nur von Microsoft angeboten
werden.

Post by Peter Fleischer

Post by Lutz Schulze
...
Ähm, wieviele Hersteller ünterstützen SQL und wieviele Hersteller
unterstützen dagegen die CLR auf dem Datenbankserver?

Bei neuen Texhnoligien beginnen immer erst mal nur wenige. CLR unterstützen
z.B. MS SQL Server 2005 in allen Versionen, Oracle 10g und DB2.

S.o. Wenn dem nicht so ist, um so besser.

Post by Peter Fleischer

Post by Lutz Schulze
Seit wann gibt es die CLR?

Seit ca. 4 Jahren und in den Datenbankservern freigegeben seit ca. 1,5
Jahren.

Post by Lutz Schulze
Wieso soll die jetzt besonders
zukunftssicher sein?

Auch wenn du nicht an eine Zukunftsischerheit glaubst, so sind die für die
Arbeit im Datenbankserver gekapselten Funktionalitäten auch außerhalb
anwendbar, falls es nach Beendung des Supports für diese Datenbankserver in
schätzungsweise 10 Jahren keine nachfolgende Unterstützung mehr gibt. Da
aber die Entwickler der genannten 3 Datenbankserver jeweils anstreben, die
Marktführerschaft zu erringen, ist es recht unwahrscheinlich, dass sie
solche Features einfach nicht weiter unterstützen werden.

Post by Lutz Schulze
Sollte das nicht mit Java auch schon mal alles
ganz super werden?

Vielleicht wird es noch. CLR-Unterstützung ist aber Realität.

Post by Lutz Schulze

Post by Peter Fleischer
Viele Lösungen kann man auch für den Kunden ausreichend
effektiv ohne moderne Technologien lösen, z.B. auch mit dBase. Aber
irgendwann kommen Forderungen, für die man ggf. auf moderne
Technologien umsteigen sollte, ...

Auf eine mit _einem_ Hersteller?

Warum willst du unbedingt eine Lösung, die nur ein Hersteller bereitstellt?
Ich verstehe deine Diskussion nicht.

Nein, das will ich eben gerade nicht. Viele MS-Lösungen waren aber in der
Vergangenheit so, dass bestehende Standards durch proprietäre Erweiterungen
erweitert und damit unterlaufen wurden. Die Liste ist recht lang, so dass da
ein gewisses Misstrauen einfach da ist.

Lutz

[Peter Fleischer]

Post by Lutz Schulze
Ich war der Meinung, dass die CLR Funktionen nur von Microsoft
angeboten werden. ...

Hi Lutz,
man sollte sich informieren und nicht einseitig orientieren. So etwas war
dein Beitrag interprtierbar.

Post by Lutz Schulze
... Viele MS-Lösungen waren aber in
der Vergangenheit so, dass bestehende Standards durch proprietäre
Erweiterungen erweitert und damit unterlaufen wurden. Die Liste ist
recht lang, so dass da ein gewisses Misstrauen einfach da ist.

Ich versuche, mich möglichst umseitig zu informieren. Das Problem bei
Microsoft mit proprietären Lösungen lag in der Vergangenheit vor allem an
der fehlenden Konkurrenz und ist seit längerem eigentlich kein Thema mehr,
wenn man sich etwas intensiver damit beschäftigt und nicht versucht, jeden
Hype schon im alpha- oder beta-Stadium mitzumachen.

[Lutz Schulze]

Post by Peter Fleischer

Post by Lutz Schulze
Ich war der Meinung, dass die CLR Funktionen nur von Microsoft
angeboten werden. ...

Hi Lutz,
man sollte sich informieren und nicht einseitig orientieren.

Na dann mache ich das gleich mal: sind die CLR-Aufrufe auf dem DB-Server
dann an MS-Windows unter dem DB-System gebunden oder gibt es das auch schon
für andere Betriebssysteme?

Lutz

[Peter Fleischer]

Post by Lutz Schulze
Na dann mache ich das gleich mal: sind die CLR-Aufrufe auf dem
DB-Server dann an MS-Windows unter dem DB-System gebunden oder gibt
es das auch schon für andere Betriebssysteme?

Hi Lutz,
die Frage kann ich dir nicht ausreichend genau beantworten, da das Umfeld so
gewaltig ist, dass man in der zur Verfügung stehenden Zeit einfach nicht
jedes Detail mitbekommt. Wenn dir das wichtig ist, dann solltest du mal im
Internet recherchieren, z.B.:

DB2 von IBM
http://www-306.ibm.com/software/info/ecatalog/de_DE/products/X105778X99620I52.html?&S_TACT=none&S_CMP=none

Oracle
http://www.oracle.com/technology/products/database/xe/index.html

SQL Server 2005 von microsoft
Erspar ich mir, da du das scheinbar sehr gut kennst.

Aus meiner Sicht sind das Hauptproblem heute bei der Nutzung der
CLR-Unterstützung die Werkzeuge. Und da sind mir keine Alternativen zum
Visual Studio (VS) bekannt, mit denen man ähnlich effektiv entwickeln kann.
Aber auch das kann sich mit der Zeit ändern. Die mit dem VS entwickelten
Anwendungen sind nicht an Windows gebunden, wobei jedoch nicht zu
unterschätzen ist, dass z.B. die Runtime Library im Projekt mono nicht alles
unterstützt, was im Framework unter Windows unterstützt wird. Da muss man
abwägen, was der Anwender wirklich benötigt und ob der Zusatzaufwand zur
Entwicklung fehlender Methoden vom Anwender bezahlt wird.

[Thomas Bernhard]

Post by Peter Fleischer
Aus meiner Sicht sind das Hauptproblem heute bei der Nutzung der
CLR-Unterstützung die Werkzeuge. Und da sind mir keine Alternativen zum
Visual Studio (VS) bekannt, mit denen man ähnlich effektiv entwickeln kann.

aha

Post by Peter Fleischer
Aber auch das kann sich mit der Zeit ändern.

oder auch nicht

Post by Peter Fleischer
Die mit dem VS
entwickelten Anwendungen sind nicht an Windows gebunden, wobei jedoch
nicht zu unterschätzen ist, dass z.B. die Runtime Library im Projekt mono
nicht alles unterstützt, was im Framework unter Windows unterstützt wird.

also inkompatibel

Post by Peter Fleischer
Da muss man abwägen, was der Anwender wirklich benötigt und ob der
Zusatzaufwand zur Entwicklung fehlender Methoden vom Anwender bezahlt
wird.

Wer Zeit und Geld übrig hat kann sich sicherlich mit vielerlei Dingen
beschäftigen.

Standardsoftware kaufen welche die Daten in einer SQL Datenbank speichert
und wo ausreichende Doku zur Verfügung steht und die Sonderfunktionen extra
programmieren. Ob man PHP nimmt oder in Microsoft Basic programmiert ist
dann eine Frage des Geschmacks.

[Peter Fleischer]

Post by Thomas Bernhard

Post by Peter Fleischer
Die mit dem VS
entwickelten Anwendungen sind nicht an Windows gebunden, wobei jedoch
nicht zu unterschätzen ist, dass z.B. die Runtime Library im Projekt
mono nicht alles unterstützt, was im Framework unter Windows
unterstützt wird.

also inkompatibel

Hi Thomas,
und was willst du damit sagen? Es gibt nirgendwo eine 100%-Kompatibiltät.
Nimm die vielen SQL-Dialekte, nimm die Unterschiede in den Versionen
genutzter Software, wobei es meist wenigstens eine angemessene
Aufwärtskompatibilität gibt.

Post by Thomas Bernhard
..
Standardsoftware kaufen

Standardsoftware ist mit sehr hoher Wahrscheinlichkeit zu den vorhandenen
und abzubildenden Orgabläufen inkompatibel.

Post by Thomas Bernhard
welche die Daten in einer SQL Datenbank
speichert und wo ausreichende Doku zur Verfügung steht und die
Sonderfunktionen extra programmieren. Ob man PHP nimmt oder in
Microsoft Basic programmiert ist dann eine Frage des Geschmacks.

Also fehlende Kompatibilität durch Zusatzaufwand ersetzen. Nichts anderes
hatte ich geschrieben.

[Thomas Bernhard]

Post by Peter Fleischer

Post by Thomas Bernhard
welche die Daten in einer SQL Datenbank
speichert und wo ausreichende Doku zur Verfügung steht und die
Sonderfunktionen extra programmieren. Ob man PHP nimmt oder in
Microsoft Basic programmiert ist dann eine Frage des Geschmacks.

Also fehlende Kompatibilität durch Zusatzaufwand ersetzen. Nichts anderes
hatte ich geschrieben.

Ja, und das man in einer Firma mit 20 MA und einer vorhandenen dBase
Datenbank nun überlegen sollte Oracle und IBM Datenbanken einzusetzen.

[Peter Fleischer]

Post by Thomas Bernhard

Post by Peter Fleischer
Also fehlende Kompatibilität durch Zusatzaufwand ersetzen. Nichts
anderes hatte ich geschrieben.

Ja, und das man in einer Firma mit 20 MA und einer vorhandenen dBase
Datenbank nun überlegen sollte Oracle und IBM Datenbanken einzusetzen.

Hi Thomas,
was gibt es da für Probleme?

Oracle XE oder SQL Server 2005 Express sind in ca. 30 Minuten installiert
und sofort arbeitsfähig. Alles weitere sind zusätzliche Arbeiten, wie
abweichende Nutzerrechte oder Rollen eintragen oder über den Designer eine
Datenbank anlegen, wenn das im Projekt nicht vorgesehen ist. Das geht heute
genauso einfach und schnell, wie beispielsweise die Arbeit mit Access. Für
die Organisation der Datensicherung ist genau so wenig erforderlich wie bei
dBase-Dateien.

[Thomas Bernhard]

Post by Peter Fleischer

Post by Thomas Bernhard

Post by Peter Fleischer
Also fehlende Kompatibilität durch Zusatzaufwand ersetzen. Nichts
anderes hatte ich geschrieben.

Ja, und das man in einer Firma mit 20 MA und einer vorhandenen dBase
Datenbank nun überlegen sollte Oracle und IBM Datenbanken einzusetzen.

Hi Thomas,
was gibt es da für Probleme?
Oracle XE oder SQL Server 2005 Express sind in ca. 30 Minuten installiert
und sofort arbeitsfähig.

Nachdem man vorher mehrere Stunden eruiert hat welche Einschränkungen diese
cripple software hat.

Die Frage stellt sich so auch nicht, die Standardsoftware kommt eh schon mit
einer Datenbank daher. Daraus leitet sich dann der Rest ab.

[Peter Fleischer]

Post by Thomas Bernhard

Post by Peter Fleischer
was gibt es da für Probleme?
Oracle XE oder SQL Server 2005 Express sind in ca. 30 Minuten
installiert und sofort arbeitsfähig.

Nachdem man vorher mehrere Stunden eruiert hat welche Einschränkungen
diese cripple software hat.

Hi Thomas,
wer keine Einsatzvorbereitung betreibt und nicht bereit ist, dafür ein paar
Stunden aufzuwenden, der handelt äußerst unverantwortlich gegenüber dem
späteren Nutzer/Anwender.

Bei den genannten Beispielen gibt es die Einschränkung auf 4 GB je
Datenbank, d.h. eine Einschränkung auf ca. 2 Mio Seiten
Schreibmaschinentext, was in etwa einem Volumen von ca. 4 GB dBase-Dateien
entspricht. Bezogen auf die Ausgangsfrage wäre zu kalkulieren, wie groß der
jetzigen Datenbestand ist und welche Steigerung in Zukunft zu erwarten ist.
In unserer Firma arbeiten 10 MA mit einer BW-Anwendung (Angebote,
Kalkulationen, Aufmaße, Bauzeitenplanung, Fibu, usw.) und produzieren pro
Jahr ca. 300 MB Daten.

Post by Thomas Bernhard
Die Frage stellt sich so auch nicht, die Standardsoftware kommt eh
schon mit einer Datenbank daher. Daraus leitet sich dann der Rest ab.

Eine Standardsoftware, die keinen konfigurierbaren Datenbanklayer hat, wäre
dann auf dem Niveau dieser Diskussion und erinnert mich an die politischen
Diskussionen, bei denen über Dinge gestritten wird (nach der uns zugeteilten
Information), die an der Realität weit vorbei geht.

[Thomas Bernhard]

Post by Peter Fleischer

Post by Thomas Bernhard

Post by Peter Fleischer
was gibt es da für Probleme?
Oracle XE oder SQL Server 2005 Express sind in ca. 30 Minuten
installiert und sofort arbeitsfähig.

Nachdem man vorher mehrere Stunden eruiert hat welche Einschränkungen
diese cripple software hat.

Hi Thomas,
wer keine Einsatzvorbereitung betreibt und nicht bereit ist, dafür ein
paar Stunden aufzuwenden, der handelt äußerst unverantwortlich gegenüber
dem späteren Nutzer/Anwender.

Das ist richtig, insbesondere wenn man cripple software einsetzen möchte.

Post by Peter Fleischer
Bei den genannten Beispielen gibt es die Einschränkung auf 4 GB je
Datenbank, d.h. eine Einschränkung auf ca. 2 Mio Seiten
Schreibmaschinentext, was in etwa einem Volumen von ca. 4 GB dBase-Dateien
entspricht.

Weitere Einschränkungen gibt es nicht, erstaunlich.

Post by Peter Fleischer

Post by Thomas Bernhard
Die Frage stellt sich so auch nicht, die Standardsoftware kommt eh
schon mit einer Datenbank daher. Daraus leitet sich dann der Rest ab.

Eine Standardsoftware, die keinen konfigurierbaren Datenbanklayer hat,
wäre dann auf dem Niveau dieser Diskussion und erinnert mich an die
politischen Diskussionen, bei denen über Dinge gestritten wird (nach der
uns zugeteilten Information), die an der Realität weit vorbei geht.

Einschränkungen wie Du sie machst führen zur Unwirtschaftlichkeit. Man kann
durchaus auch Standardsoftware ohne konfigurierbaren Datenbanklayer
einsetzen.

Ich wiederhole: 20 MA und vorhandene dBase Datenbank.
Ohne Kenntnis der Branche und der speziellen Anforderungen ist es schwer
einen brauchbaren Rat zu geben. Die theoretischen Möglichkeiten hat der OP
ja schon selbst hinreichend beschrieben.

[Peter Fleischer]

Post by Thomas Bernhard

Post by Peter Fleischer

Post by Thomas Bernhard

Post by Peter Fleischer
Oracle XE oder SQL Server 2005 Express sind in ca. 30 Minuten
installiert und sofort arbeitsfähig.

Nachdem man vorher mehrere Stunden eruiert hat welche
Einschränkungen diese cripple software hat.

Hi Thomas,
wer keine Einsatzvorbereitung betreibt und nicht bereit ist, dafür
ein paar Stunden aufzuwenden, der handelt äußerst unverantwortlich
gegenüber dem späteren Nutzer/Anwender.

Das ist richtig, insbesondere wenn man cripple software einsetzen möchte.

Post by Peter Fleischer
Bei den genannten Beispielen gibt es die Einschränkung auf 4 GB je
Datenbank, d.h. eine Einschränkung auf ca. 2 Mio Seiten
Schreibmaschinentext, was in etwa einem Volumen von ca. 4 GB
dBase-Dateien entspricht.

Weitere Einschränkungen gibt es nicht, erstaunlich.

Hi Thomas,
cripple software, cripple spirit und cripple knowledge sind wohl deine
Spezialgebiete, dass du ohne Kenntnis darüber immer darauf verweist?

Post by Thomas Bernhard
...
Ich wiederhole: 20 MA und vorhandene dBase Datenbank.
Ohne Kenntnis der Branche und der speziellen Anforderungen ist es
schwer einen brauchbaren Rat zu geben. Die theoretischen
Möglichkeiten hat der OP ja schon selbst hinreichend beschrieben.

Warum soll einem Fragesteller nicht konkret geantwortet werden? Und das, was
er an Input geboten hat in der Fragestellung, war schon recht konkret, um
darauf aufbauend eigene Erfahrungen und Kenntnisse zu vermitteln.
Entscheiden muss erletztendlich sowieso selbst.

[Thomas Bernhard]

Post by Peter Fleischer

Post by Thomas Bernhard

Post by Peter Fleischer
Bei den genannten Beispielen gibt es die Einschränkung auf 4 GB je
Datenbank, d.h. eine Einschränkung auf ca. 2 Mio Seiten
Schreibmaschinentext, was in etwa einem Volumen von ca. 4 GB
dBase-Dateien entspricht.

Weitere Einschränkungen gibt es nicht, erstaunlich.

Hi Thomas,
cripple software, cripple spirit und cripple knowledge sind wohl deine
Spezialgebiete, dass du ohne Kenntnis darüber immer darauf verweist?

Es gibt weitere Nachteile über die man nicht sprechen mag?

[Andreas Scherbaum]

Post by Aleks A.-Lessmann
Mit PostGre

http://stoned.homeunix.org/~itsme/postgre/

*pingelig bin*


Bis dann

[Heinrich Butschal]

Post by Ekki Plicht

Post by Heinrich Butschal
Neuer und moderner soll doch wohl in erster Linie die GUI werden - oder?

Ja, und weg von DOS(!). Wir bekommen bald keine Hardware mehr dafür ;.)

Jetztaaa, kommen die echten Informationen, vorher klang alles so harmlos und nett.

Post by Ekki Plicht

Post by Heinrich Butschal
Dann kann doch jemand sich damit beschäftigen die Module in z.B .Net zu
schreiben. Der Zugriff auf die vorhandenen Tabellen könnte doch bleiben?

.Net ok, vorhandene Tabellen liegen im .dbf/.mdx Format vor und ich glaube
kaum das wir die behalten wollen/sollten. Es gibt in der Tat gelegentlich
Zugriffsfehler, da kommt der Index durcheinander. Der drohende Aufwand
_den_ Fehler zu finden lässt eine Migration zu einem komplett neuen System
kleiner erscheinen.
Es soll ein zentraler Server mit MySql, postgres o.ä. eingesetzt werden.

Post by Heinrich Butschal
Never touch a running ....

Ok, bei zunehmend kleiner werdenden Werten von 'running' steigt der
Leidensdruck dann doch. Ich frag hier ja nicht aus Spaß :-)

Nun ursprünglich sollte es nur "moderner" werden - das wäre Spaß.

Post by Ekki Plicht

Post by Heinrich Butschal
Oder benötigt Ihr transaktionfähige Datenbanken weil die User sich sonst die
Daten gegenseitig gleichzeitig überschrieben haben?

Ja, s.o.

Das ist ein Problem - weil bekannt - auch vermutet.

Post by Ekki Plicht

Post by Heinrich Butschal
Dann ist eine Migration eigentlich des ganzen Systems fast unausweichlich.

Eben. Es geht jetzt 'nur noch' um den schmerzfreiesten Weg dorthin.
Danke & Gruß,
Ekki

Kleiner Vorschlag:
1. alle Applikationen und Schnittstellen exact beschreiben (lassen)
2. bewertet mit "gerne" "wichtig" "essentiell" ein Pflichtenheft erstellen
3. dann wiederkommen und nach Lösungen suchen (Evaluation)

Mit freundlichem Gruß,
Heinrich Butschal

[Matthias Kryn]

Ekki Plicht schrieb:

Hallo Ekki,

Post by Ekki Plicht
Ich hoffe ich bin hier einigermassen richtig.

Ja, absolut. Herzlich willkommen in debs.

Post by Ekki Plicht
Wir, eine mittelständische Fa. mit 20 Angestellten, sind
dabei uns von unserer bisherigen Software zu verabschieden.

Oh. Ist es soweit?

Post by Ekki Plicht
Optionen wie wir Sie sehen
--------------------------
1) Standardsoftware kaufen.
2) Standardpaket mit Anpassungen kaufen, Support vom
3) Komplett selber schreiben.
4) Vorhandenes Opensource Projekt nehmen und sich dranhängen,
War's das an Möglichkeiten?

Ganz abstrakt gesehen: ja.

Post by Ekki Plicht
Wie würdet ihr an so ein Projekt rangehen?

Vor allem bietet es sich an, bei diesem großen Schritt alle
kleinen Nickligkeiten mit zu erschlagen. Wieviel eurer
Gesshäftsprozesse und der bisherigen Software ist denn
dokumentiert? Und mehr noch, wieviel eurer Geschäfsprozesse ist
_umsetzungsfähig_ (hinreichend genau spezifiziert) dokumentiert?

Grüße
Matthias

[Ekki Plicht]

Post by Matthias Kryn
Hallo Ekki,

Post by Ekki Plicht
Ich hoffe ich bin hier einigermassen richtig.

Ja, absolut. Herzlich willkommen in debs.

Hallo Matthias,
irgendwie hätte ich mir denken sollen das ich Dich hier treffe :-) Schön.

Post by Matthias Kryn

Post by Ekki Plicht
Wir, eine mittelständische Fa. mit 20 Angestellten, sind
dabei uns von unserer bisherigen Software zu verabschieden.

Oh. Ist es soweit?

Ja.
Sehe ich da Eurozeichen in Deinen Augen?

Post by Matthias Kryn
Vor allem bietet es sich an, bei diesem großen Schritt alle
kleinen Nickligkeiten mit zu erschlagen.

Gerade die kleinen Nickeligkeiten sind es die uns daran festhalten lassen,
die Software selber pflegen zu können. Heute ist es so das ein Mitarbeiter
aus der Praxis heraus sagt "Du, könnte man das nicht so und so machen?".
Dann guckt sich das wer an, sagt ja und macht. 30 Minuten später ist die
kleine Nickeligkeit raus.
Das meinte ich mit perfekt angepasst.

Post by Matthias Kryn
Wieviel eurer
Gesshäftsprozesse und der bisherigen Software ist denn
dokumentiert? Und mehr noch, wieviel eurer Geschäfsprozesse ist
_umsetzungsfähig_ (hinreichend genau spezifiziert) dokumentiert?

Imemr diese Fremdworte - 'dokumentiert'. Damit kam schon vorher jemand.
Matthias, morgen fragst Du mich nach ISO-9001/9002 oder so.

Nein, der Dokumentationsstand ist wie im richtigen Leben - erschreckend
unvorhanden. Es gibt für alles Prozeduren und Abläufe, seit dem ich hier
bin ein paar mehr, aber im wesentlichen in den Köpfen der Leute.

Dennoch - ich werde ein Pflichtenheft aufgrund der vorhandenen Software
erstellen, das dann natürlich auch die Betriebsabläufe besser darstellt.

Vieles ist halt gewachsen, wobei aber der Spruch "Das ham wa schon immer so
gemacht!!eins!" hier verboten ist.

Gruß,
Ekki

[Matthias Kryn]

Hallo Ekki,

Post by Ekki Plicht
irgendwie hätte ich mir denken sollen das ich Dich hier
treffe :-) Schön.

Post by Matthias Kryn

Post by Ekki Plicht
Wir, eine mittelständische Fa. mit 20 Angestellten, sind
dabei uns von unserer bisherigen Software zu
verabschieden.

Oh. Ist es soweit?

Ja.
Sehe ich da Eurozeichen in Deinen Augen?

Ui -- bin ich so leicht zu durchschauen? Ja, das auch.

Als Selbständiger sollte man wenigstens ab und zu an Umsatz und
Ertrag denken :-)

Post by Ekki Plicht

Post by Matthias Kryn
Vor allem bietet es sich an, bei diesem großen Schritt alle
kleinen Nickligkeiten mit zu erschlagen.

Gerade die kleinen Nickeligkeiten sind es die uns daran
festhalten lassen, die Software selber pflegen zu können.
Heute ist es so das ein Mitarbeiter aus der Praxis heraus
sagt "Du, könnte man das nicht so und so machen?". Dann guckt
sich das wer an, sagt ja und macht. 30 Minuten später ist die
kleine Nickeligkeit raus.
Das meinte ich mit perfekt angepasst.

Ja, klar. Ich kenne und verstehe das. Das ist _das_ unschlagbare
Argument für Individualprogrammierung: die Software passt sich
an Prozesse an, nicht der Mensch an das, was der
Softwarearchitekt sich vorgestellt hat, wie ein optimaler
Geschäftsablauf sein müsse.

(Disclaimer: natürlich hilft der wechselseitige Abgleich von
individuellen, gewohnten Abläufen und einer abstrakteren Sicht.)

Post by Ekki Plicht

Post by Matthias Kryn
Wieviel eurer
Gesshäftsprozesse und der bisherigen Software ist denn
dokumentiert? Und mehr noch, wieviel eurer Geschäfsprozesse
ist _umsetzungsfähig_ (hinreichend genau spezifiziert)
dokumentiert?

Imemr diese Fremdworte - 'dokumentiert'. Damit kam schon
vorher jemand. Matthias, morgen fragst Du mich nach
ISO-9001/9002 oder so.

Soweit will ich gar nicht gehen, denn diese Zertifizierung
kostet -- und das ist Dir wahrscheinlich bekannt -- einige
TEuro.

Aaaber: existierte eine Dokumentation, könnte man diese z.B. mit
in das Pflichtenheft einfließen lassen; und derjenige, der zu
erklären hat, müsste nicht immer aufs Neue sich den Mund fusslig
reden, bis ein Externer kapiert hat, worum es geht.

Deswegen bin ich auch ein Freund von seitenlangen
Besprechungsprotokollen geworden.

Post by Ekki Plicht
Nein, der Dokumentationsstand ist wie im richtigen Leben -
erschreckend unvorhanden. Es gibt für alles Prozeduren und
Abläufe, seit dem ich hier bin ein paar mehr, aber im
wesentlichen in den Köpfen der Leute.
Dennoch - ich werde ein Pflichtenheft aufgrund der
vorhandenen Software erstellen, das dann natürlich auch die
Betriebsabläufe besser darstellt.

Wen das so ist, wie ich mir ein richtig gutes[tm] Pflichtenheft
vorstelle, dann sind das bei euch bestimmt 80 Seiten. Eher mehr.

Wobei ich so herangehen würde, dass ich primär Anforderungen
definieren und darin nicht _zu_ konkret formulieren würde. Der
Blick von außen hilft manchmal, Abläufe und Prozesse oder
Formulare einfacher, übersichtlicher und intuitiver zu
gestalten. (Auch hier gilt: nicht immer ist "neu" auch "gut".)

Post by Ekki Plicht
Vieles ist halt gewachsen, wobei aber der Spruch "Das ham wa
schon immer so gemacht!!eins!" hier verboten ist.

Jut.

Grüße
Matthias

[Kroni]

Post by Ekki Plicht
4) Vorhandenes Opensource Projekt nehmen und sich dranhängen, z.B. CAO. Da
könnte man am Entwicklungsprozess teilnehmen, eigene Entwicklungen
einfliessen lassen bzw. einen eigenen Fork bauen. Hohe Flexibilität und man
fängt nicht bei Null an.

Ist eine Möglichkeit.

Ich glaube die hängen an einer Firebird oder MySQL Datenbank.
Besser wäre da vielleicht für die Zukunft auf SQL Server zu setzen.


Und umbauen ist auch oftmals aufwendiger als gleich
was neues zu machen.
Hängt davon ab wie spezifisch und umfangreich eure Sachen sind.



K.R.

[Monsieur Ibrahim]

Post by Kroni

Post by Ekki Plicht
4) Vorhandenes Opensource Projekt nehmen und sich dranhängen, z.B. CAO. Da
könnte man am Entwicklungsprozess teilnehmen, eigene Entwicklungen
einfliessen lassen bzw. einen eigenen Fork bauen. Hohe Flexibilität und man
fängt nicht bei Null an.

Ist eine Möglichkeit.
Ich glaube die hängen an einer Firebird oder MySQL Datenbank.
Besser wäre da vielleicht für die Zukunft auf SQL Server zu setzen.

MySQL sollte für ein Unternehmen mit 20 Mitarbeiter durchaus ausreichen.

Post by Kroni
Und umbauen ist auch oftmals aufwendiger als gleich
was neues zu machen.

Nö, wenn es von Anfang an eingeplant wird, kann die Datenbank einfach
"umgehängt" werden. Bei PHP gibt es bespielsweise ADOdb, mit der man
Datenbank-unabhängig entwickeln kann.

Post by Kroni
Hängt davon ab wie spezifisch und umfangreich eure Sachen sind.

s.o. Kein Problem mit PHP und ADOdb.

BTW ich würde für dieses Projekt PHP mit Datenbank MySQL empfehlen.
Vorteile: Offen, Anpassung relativ einfach, Eigenleistung möglich
(Layout kann bspw. selbst erstellt/angepasst werden zB mit Layout der
eigenen Webseite), Intranet/Internet fähig, keine Installationen auf dem
Client notwendig (nur Internet Browser), keine besonderen
Clientanforderungen, kein unötiges MS Gedöhns, das nach max. 5 Jahren
nicht mehr supported wird [...]

Gruß
Ibrahim

[Olaf Mueller]

Post by Monsieur Ibrahim
BTW ich würde für dieses Projekt PHP mit Datenbank MySQL empfehlen.

Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

Ich, der hauptsächlich sein Geld mit Webentwicklung verdient, würde
darum einen ganz großen Bogen machen.

Post by Monsieur Ibrahim
kein unötiges MS Gedöhns, das nach max. 5 Jahren
nicht mehr supported wird [...]

Schwachsinn.

Freundlichste Grüße

[Monsieur Ibrahim]

Post by Olaf Mueller

Post by Monsieur Ibrahim
BTW ich würde für dieses Projekt PHP mit Datenbank MySQL empfehlen.

Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

Es kommt auf die GUI-Anforderungen an. Soweit ich verstanden habe, soll
hier kein 3D-Spiel, sondern eine WaWI entwickelt werden. Die
GUI-Anforderungen dafür halten sich imho in Grenzen und sollten auch
rund um PHP machbar sein.

Post by Olaf Mueller
Ich, der hauptsächlich sein Geld mit Webentwicklung verdient, würde
darum einen ganz großen Bogen machen.

Habe einige Anwendungen für Kunden mit PHP realisiert und bin davon sehr
angetan. Mag sein, dass der Aufwand für die GUI (anfangs) etwas höher
ist, aber dafür gehen andere Sachen wieder schneller/besser. Außerdem
gibt es jede Menge Vorlagen, Funktionen und Bibliotheken, die einfach
eingebunden werden können, wie zB ADOdb für den flexiblen Datenbank-Zugriff.

Post by Olaf Mueller

Post by Monsieur Ibrahim
kein unötiges MS Gedöhns, das nach max. 5 Jahren
nicht mehr supported wird [...]

Schwachsinn.

6 Jahre? 8 Jahre? Welche alten (>= 8 Jahre) MS Anwendungen können heute
ohne Problem weiterentwickelt werden? (Ganz abgesehen davon, dass man
keine Entwickler mehr dafür findet.)

Gruß
Ibrahim

[Olaf Müller]

Post by Monsieur Ibrahim

Post by Olaf Mueller
Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

Es kommt auf die GUI-Anforderungen an. Soweit ich verstanden habe, soll
hier kein 3D-Spiel, sondern eine WaWI entwickelt werden. Die
GUI-Anforderungen dafür halten sich imho in Grenzen und sollten auch
rund um PHP machbar sein.

Lade dir doch mal Visual Studio Express runter (kostet nichts) und
erstelle dir unter beliebiger Aufgabenstellung ein Interface mit
WinForms. Wenn du es noch moderner willst, kannst du dir auch dazu
noch Expression Blend ziehen, und damit die Oberfläche bauen.

Und dann ziehe mal den Vergleich mit einem HTML-Formular ... da musst
du mit JavaScript ne Menge frickeln, um annähernd den Komfort zu
bekommen.

Post by Monsieur Ibrahim
Habe einige Anwendungen für Kunden mit PHP realisiert und bin davon sehr
angetan. Mag sein, dass der Aufwand für die GUI (anfangs) etwas höher
ist, aber dafür gehen andere Sachen wieder schneller/besser. Außerdem
gibt es jede Menge Vorlagen, Funktionen und Bibliotheken, die einfach
eingebunden werden können, wie zB ADOdb für den flexiblen Datenbank-Zugriff.

Gibt es mit .NET/Java auch.

Post by Monsieur Ibrahim
6 Jahre? 8 Jahre? Welche alten (>= 8 Jahre) MS Anwendungen können heute
ohne Problem weiterentwickelt werden? (Ganz abgesehen davon, dass man
keine Entwickler mehr dafür findet.)

Wer pflegt heute noch Lasso/Filemaker-Anwendungen, oder 1997 in Perl
gescriptete Webanwendungen? Was ist mit PHP < 4? Alles hat sein
Verfallsdatum - bei Java/.NET kann man sich aber sicher sein, dass da
eine Zukunftstrategie dahintersteckt und nicht "in den Tag hinein
entwickelt wird".

Grüße

[Monsieur Ibrahim]

Post by Olaf Müller

Post by Monsieur Ibrahim

Post by Olaf Mueller
Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

Es kommt auf die GUI-Anforderungen an. Soweit ich verstanden habe, soll
hier kein 3D-Spiel, sondern eine WaWI entwickelt werden. Die
GUI-Anforderungen dafür halten sich imho in Grenzen und sollten auch
rund um PHP machbar sein.

Lade dir doch mal Visual Studio Express runter (kostet nichts) und
erstelle dir unter beliebiger Aufgabenstellung ein Interface mit
WinForms. Wenn du es noch moderner willst, kannst du dir auch dazu
noch Expression Blend ziehen, und damit die Oberfläche bauen.

Für PHP gibt es ebenfalls diverse Form-Generatoren, zB PHPRunner
generiert Formulare und PHP Code auf Basis einer oder mehrer
Datenbanktabellen. Das Ergebnis ist durchaus brauchbar und kann für die
eigene Anwendung angepasst werden. DelphiforPHP wurde auch noch erwähnt,
dass muss ich mir mal bei Gelegenheit ansehen.

Post by Olaf Müller
Und dann ziehe mal den Vergleich mit einem HTML-Formular ... da musst
du mit JavaScript ne Menge frickeln, um annähernd den Komfort zu
bekommen.

Bisher kam ich mit sehr wenig JavaScript aus, das Handling ist halt ein
bisschen anders, aber nicht unbedingt schlechter. Bei Anwendungen dieser
Art steht m.E. die Funktionalität im Vordergrund. Außerdem, was heute
cool aussieht, ist in ca. 2-3 Jahren doch schon wieder altmodisch.

Post by Olaf Müller

Post by Monsieur Ibrahim
6 Jahre? 8 Jahre? Welche alten (>= 8 Jahre) MS Anwendungen können heute
ohne Problem weiterentwickelt werden? (Ganz abgesehen davon, dass man
keine Entwickler mehr dafür findet.)

Wer pflegt heute noch Lasso/Filemaker-Anwendungen, oder 1997 in Perl
gescriptete Webanwendungen? Was ist mit PHP < 4? Alles hat sein
Verfallsdatum - bei Java/.NET kann man sich aber sicher sein, dass da
eine Zukunftstrategie dahintersteckt und nicht "in den Tag hinein
entwickelt wird".

PHP dürfte es auch noch einige Zeit geben, wer weiß schon was länger lebt.
Aber der entscheidende Vorteil bei PHP: Es ist kein Problem _einen_
Application Server auf eine kompatible PHP-Version einzufrieren, mach
das mal mit allen Clients. Die Clients könnten sogar von Windows auf
bspw. Linux umgestellt werden, die PHP-Anwendung läuft immernoch.

Gruß
Ibrahim

[Peter Fleischer]

Post by Monsieur Ibrahim
Für PHP gibt es ebenfalls diverse Form-Generatoren, zB PHPRunner
generiert Formulare und PHP Code auf Basis einer oder mehrer
Datenbanktabellen. Das Ergebnis ist durchaus brauchbar und kann für
die eigene Anwendung angepasst werden. DelphiforPHP wurde auch noch
erwähnt, dass muss ich mir mal bei Gelegenheit ansehen.

Auch für dBase gibt es diverse Hilsprogramme. Deshalb wird dBase aber nicht
moderner :-)

Post by Monsieur Ibrahim

Post by Olaf Müller
Und dann ziehe mal den Vergleich mit einem HTML-Formular ... da musst
du mit JavaScript ne Menge frickeln, um annähernd den Komfort zu
bekommen.

Bisher kam ich mit sehr wenig JavaScript aus, das Handling ist halt
ein bisschen anders, aber nicht unbedingt schlechter. Bei Anwendungen
dieser Art steht m.E. die Funktionalität im Vordergrund. Außerdem,
was heute cool aussieht, ist in ca. 2-3 Jahren doch schon wieder
altmodisch.

Bei ASP.NET braucht man für die gängigen Anwendungen auch keinen eigene
JavaScript.

Post by Monsieur Ibrahim

Post by Olaf Müller

Post by Monsieur Ibrahim
6 Jahre? 8 Jahre? Welche alten (>= 8 Jahre) MS Anwendungen können
heute ohne Problem weiterentwickelt werden? (Ganz abgesehen davon,
dass man keine Entwickler mehr dafür findet.)

Wer pflegt heute noch Lasso/Filemaker-Anwendungen, oder 1997 in Perl
gescriptete Webanwendungen? Was ist mit PHP < 4? Alles hat sein
Verfallsdatum - bei Java/.NET kann man sich aber sicher sein, dass da
eine Zukunftstrategie dahintersteckt und nicht "in den Tag hinein
entwickelt wird".

PHP dürfte es auch noch einige Zeit geben, wer weiß schon was länger
lebt. Aber der entscheidende Vorteil bei PHP: Es ist kein Problem
_einen_ Application Server auf eine kompatible PHP-Version
einzufrieren, mach das mal mit allen Clients. Die Clients könnten
sogar von Windows auf bspw. Linux umgestellt werden, die
PHP-Anwendung läuft immernoch.

Warum die alte PHP-Technologie, wenn es ASP.NET gibt. Jeder Client braucht
da genau so nur einen Browser - egal welcher.

[Lars Wilke]

Post by Olaf Müller

Post by Monsieur Ibrahim

Post by Olaf Mueller
Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

Es kommt auf die GUI-Anforderungen an. Soweit ich verstanden habe, soll
[...]

Und dann ziehe mal den Vergleich mit einem HTML-Formular ... da musst
du mit JavaScript ne Menge frickeln, um annähernd den Komfort zu
bekommen.

FULL ACK. Ein Rich Client mit einer Web Anwendung zu vergleichen bzw.
die Web Anwendung ein ähnliches Look 'n Feel zu geben ist hart[tm].

Post by Olaf Müller

Post by Monsieur Ibrahim
Habe einige Anwendungen für Kunden mit PHP realisiert und bin davon sehr
angetan. Mag sein, dass der Aufwand für die GUI (anfangs) etwas höher
ist, aber dafür gehen andere Sachen wieder schneller/besser. Außerdem
gibt es jede Menge Vorlagen, Funktionen und Bibliotheken, die einfach
eingebunden werden können, wie zB ADOdb für den flexiblen Datenbank-Zugriff.

Gibt es mit .NET/Java auch.

... und Python, Ruby und vermtl. noch ein paar anderen Sprachen.

Post by Olaf Müller

Post by Monsieur Ibrahim
6 Jahre? 8 Jahre? Welche alten (>= 8 Jahre) MS Anwendungen können heute
ohne Problem weiterentwickelt werden? (Ganz abgesehen davon, dass man
keine Entwickler mehr dafür findet.)

Wer pflegt heute noch Lasso/Filemaker-Anwendungen, oder 1997 in Perl
gescriptete Webanwendungen? Was ist mit PHP < 4? Alles hat sein

Also bei Perl muss ich die Hand heben und Neee, dass ist kein Spaß.

Post by Olaf Müller
Verfallsdatum - bei Java/.NET kann man sich aber sicher sein, dass da
eine Zukunftstrategie dahintersteckt und nicht "in den Tag hinein
entwickelt wird".

Ja, aber zumindest in den dynamischen Sprachen kannst du schnell
entwickeln und Support für diese Sprachen findest du sicher noch in 10
Jahren. Siehe Perl. Gibt imho nichts portableres. Ausser vielleicht
POSIX C.

Vielleicht sollte der OP erstmal tief in sich gehen und sich überlegen
ob es wirklich eine Web-Anwendung sein soll.

Hm, IIUC gibt es in der Firma doch schon einen Entwickler, oder nicht?
Wäre es nicht am besten diesen zu schulen und den was neues schreiben zu
lassen. Denn ein so angepasstes System ist nicht mal eben einfach so
portiert bzw. neu erstellt und das unabhängig von der Technik.

Gruß
--lars

[Matthias Frey]

Post by Lars Wilke
Hm, IIUC gibt es in der Firma doch schon einen Entwickler, oder nicht?
Wäre es nicht am besten diesen zu schulen und den was neues schreiben zu
lassen. Denn ein so angepasstes System ist nicht mal eben einfach so
portiert bzw. neu erstellt und das unabhängig von der Technik.

Einen Entwickler der bislang nur mit dbase "rumgemacht" hat und
nicht selber aktiv war?
Also einbeziehen würde ich den Entwickler auf jeden Fall. Sein
Wissen ist zu kostbar. Im muss eine Perspektive auch für
die Zukunft geboten werden.
Vielleicht ist eine Zusammenarbeit denkbar? Externe Entwickler
entwickeln die Software gemeinsam mit ihm und er pflegt diese
dann weiter?

Post by Lars Wilke
Gruß
--lars

Grüße
Matthias

[Lars Wilke]

Post by Matthias Frey

Post by Lars Wilke
Hm, IIUC gibt es in der Firma doch schon einen Entwickler, oder nicht?
Wäre es nicht am besten diesen zu schulen und den was neues schreiben zu
lassen. Denn ein so angepasstes System ist nicht mal eben einfach so
portiert bzw. neu erstellt und das unabhängig von der Technik.

Einen Entwickler der bislang nur mit dbase "rumgemacht" hat und
nicht selber aktiv war?

Hm, kommt wohl auf die Auslegung von "rumgemacht" an :)
Wie aktiv bzw. aufnahmefähig der ist kann ich dem Posting
des OP nicht entnehmen, aber er ist der der die bestehenden
Prozesse in Code gehauen hat. Er ist der, wenn überhaupt jemand,
der den Code noch lesen kann.
Daher ist es IMHO sehr Sinnvoll diesen im Hause zu behalten.

Post by Matthias Frey
Also einbeziehen würde ich den Entwickler auf jeden Fall. Sein
Wissen ist zu kostbar. Im muss eine Perspektive auch für
die Zukunft geboten werden.

ACK. IMO wäre es gut ihn im Zielsystem/Sprache zu schulen und dann
als Team das Teil zu entwickeln. Mit der Zielsetzung, dass der Externe
nach und nach in den Hintergrund gehen kann.

Post by Matthias Frey
Vielleicht ist eine Zusammenarbeit denkbar? Externe Entwickler
entwickeln die Software gemeinsam mit ihm und er pflegt diese
dann weiter?

Ja z.B., keine Ahnung wie festgefahren dieser Entwickler eben ist.
Aber so ein Modell wäre sicher möglich. Eventl. liefert man diesem
einen Rahmen den er dann nach und nach immer mehr selber ausfüllt.
Vorteil, es sind zwei Leute zum Supporten da, der Externe nach ein
paar Jahren zumindest immer noch rudimentär.
Diesmal Doku nicht vergessen ;)

Zwei Leute sind aber freilich teurer als einer ...

just my €0,02

--lars

[Ekki Plicht]

Post by Lars Wilke
Vielleicht sollte der OP erstmal tief in sich gehen und sich überlegen
ob es wirklich eine Web-Anwendung sein soll.

Gerne. Ich habe das mit der Web-Anwendung nicht vorgeschlagen und sehe das
Stand heute auch nicht als eine mögliche Lösung. Einige Funktionen ja, aber
alles? Ich glaube kaum.

Post by Lars Wilke
Hm, IIUC gibt es in der Firma doch schon einen Entwickler, oder nicht?
Wäre es nicht am besten diesen zu schulen und den was neues schreiben zu
lassen. Denn ein so angepasstes System ist nicht mal eben einfach so
portiert bzw. neu erstellt und das unabhängig von der Technik.

Der Programmierer hier hat mit wachsendem Laden mittlerweile genug anderes
zu tun. Na mal sehen, wir sind noch sehr früh in der Planung, ich sammele
derzeit nur erstmal Ideen um sicherzustellen, das wir nicht alles
übersehen.

Gruß,
Ekki

[Peter Fleischer]

Post by Ekki Plicht
...
Gerne. Ich habe das mit der Web-Anwendung nicht vorgeschlagen und
sehe das Stand heute auch nicht als eine mögliche Lösung. Einige
Funktionen ja, aber alles? Ich glaube kaum.

Hi Ekki,
wenn man skalierbar bleiben will (veränderte Nutzerzahhl, Berechtigungen,
Standorte), sollte die Web-Nutzung auch betrachtet werden. Über das Intranet
oder auch bei Notwendigkeit über das Internet werden webServices
bereitgestllt, die allein mit der Datenbank kominizieren. Auf die
WebServices können Client-Lösungen und WebSites zugreifen, ohne dass beim
WebService bzw. der Datenbank irgend etwas zu ändern bzw. zu unterscheiden
ist. Lediglich, wenn die Hardware zu schwach ist (langsamer Server), dann
würde eine zwischengeschaltete Ebene möglicherweise bremsen. Andererseits
kann solch eine zwischengeschaltete Ebene den Datentransfer reduzieren
helfen und damit wieder Performancegewinne ermöglichen.

[Martin Hentrich]

Post by Olaf Mueller

Post by Monsieur Ibrahim
BTW ich würde für dieses Projekt PHP mit Datenbank MySQL empfehlen.

Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

http://www.codegear.com/Downloads/TrialandFreeVersions/Delphi/DelphiforPHP/tabid/250/Default.aspx

Martin

[Lutz Schulze]

Post by Martin Hentrich

Post by Olaf Mueller

Post by Monsieur Ibrahim
BTW ich würde für dieses Projekt PHP mit Datenbank MySQL empfehlen.

Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

http://www.codegear.com/Downloads/TrialandFreeVersions/Delphi/DelphiforPHP/tabid/250/Default.aspx

Ähm. Tummelt sich hier auf der Platte. Ein Manual wäre schon mal nicht
schlecht gewesen, vielleicht habe ich das bisher auch nur übersehen.

Mir sind Anwendungen im Browser (die ich eigentlich mag) irgendwie auch
immer zu langsam. Aber vielleicht wird das ja noch.

Lutz

[Monsieur Ibrahim]

Post by Lutz Schulze

Post by Martin Hentrich

Post by Olaf Mueller

Post by Monsieur Ibrahim
BTW ich würde für dieses Projekt PHP mit Datenbank MySQL empfehlen.

Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

http://www.codegear.com/Downloads/TrialandFreeVersions/Delphi/DelphiforPHP/tabid/250/Default.aspx

Ähm. Tummelt sich hier auf der Platte. Ein Manual wäre schon mal nicht
schlecht gewesen, vielleicht habe ich das bisher auch nur übersehen.

Ist doch eigentlich ziemlich intuitiv gemacht. Ich hab' mir das vorhin
runter geladen und bereits eine kleine GUI damit erstellt. Sieht gut
aus, wie ein Windows Proggi im Browser (wenns denn unbedingt
Windows-like sein muss ;-). Wird aber ziemlich viel JavaScript
generiert, für meinen Geschmack könnte es etwas weniger sein.

Post by Lutz Schulze
Mir sind Anwendungen im Browser (die ich eigentlich mag) irgendwie auch
immer zu langsam. Aber vielleicht wird das ja noch.

Hmm, die kleine GUI (s.o.) läuft richtig flott. Vermutlich bremst eher
das Internet. Im Intranet kann man recht schnelle PHP-Anwendungen
entwickeln.

Gruß
Ibrahim

[Lutz Schulze]

Post by Monsieur Ibrahim

Post by Lutz Schulze
Ähm. Tummelt sich hier auf der Platte. Ein Manual wäre schon mal nicht
schlecht gewesen, vielleicht habe ich das bisher auch nur übersehen.

Ist doch eigentlich ziemlich intuitiv gemacht. Ich hab' mir das vorhin
runter geladen und bereits eine kleine GUI damit erstellt. Sieht gut
aus, wie ein Windows Proggi im Browser (wenns denn unbedingt
Windows-like sein muss ;-). Wird aber ziemlich viel JavaScript
generiert, für meinen Geschmack könnte es etwas weniger sein.

Das bringt Ajax wohl so mit sich. Zur Doku: frühere Borland-Manuals setzen
da Maßstäbe, aber die Zeiten ändern sich auch hier.

Wenn ich aber in der VCL-Referenz von Delphi für PHP nach der Syntax von
irgendwas suche, kommt ausser der automatisch generierten Auflistung der
Klassen und Methoden _nichts_. So ist das eigentlich unbrauchbar, oder suche
ich am falschen Fleck?

Klar kann man die Beispiele auswerten, aber so etwas wie zum Beispiel

$this->ListBox1->Items[0] = $this->Edit1->Text;

fällt mir nicht unbedingt intuitiv beim eintippern ein.

Dann wollte ich doch mal schauen, womit ich dann Einträge anhängen kann
(Items ist ja ein Array, aber wahrscheinlich gibt es dafür auch eine Methode
des Objekts), habe da aber in der Referenz ausser Leere nichts gefunden. Da
gibt es wohl noch einiges zu tun.

Ansonsten finde ich das Konzept gut.

Lutz

[Peter Fleischer]

Post by Martin Hentrich

Post by Olaf Mueller

Post by Monsieur Ibrahim
BTW ich würde für dieses Projekt PHP mit Datenbank MySQL empfehlen.

Du bist dir bewusst, welchen Aufwand du treiben musst, um annähernd
die Qualität des GUI einer Destkop-Anwendung hinzubekommen?

http://www.codegear.com/Downloads/TrialandFreeVersions/Delphi/DelphiforPHP/tabid/250/Default.aspx

Hi Martin,
die Nutzung von 2 alten Technologien bedeutet nicht zwangsläufig, dass die
Anwendung dann modern und zukunftträchtig wird. :-)

[Ekki Plicht]

Post by Monsieur Ibrahim

Post by Kroni

Post by Ekki Plicht
4) Vorhandenes Opensource Projekt nehmen und sich dranhängen, z.B. CAO. Da
könnte man am Entwicklungsprozess teilnehmen, eigene Entwicklungen
einfliessen lassen bzw. einen eigenen Fork bauen. Hohe Flexibilität und man
fängt nicht bei Null an.

Ist eine Möglichkeit.
Ich glaube die hängen an einer Firebird oder MySQL Datenbank.
Besser wäre da vielleicht für die Zukunft auf SQL Server zu setzen.

MySQL sollte für ein Unternehmen mit 20 Mitarbeiter durchaus ausreichen.

Post by Kroni
Und umbauen ist auch oftmals aufwendiger als gleich
was neues zu machen.

Nö, wenn es von Anfang an eingeplant wird, kann die Datenbank einfach
"umgehängt" werden. Bei PHP gibt es bespielsweise ADOdb, mit der man
Datenbank-unabhängig entwickeln kann.

Post by Kroni
Hängt davon ab wie spezifisch und umfangreich eure Sachen sind.

s.o. Kein Problem mit PHP und ADOdb.
BTW ich würde für dieses Projekt PHP mit Datenbank MySQL empfehlen.

MySQL verstehe ich, aber PHP? Das wäre mir nun für eine Büroapplikation
wahrscheinlich als Letztes eingefallen. Ok ok, noch vor Brainfsck und Piet.

Dann würde ich das aber lieber in Perl machen :-)

Post by Monsieur Ibrahim
Vorteile: Offen, Anpassung relativ einfach, Eigenleistung möglich
(Layout kann bspw. selbst erstellt/angepasst werden zB mit Layout der
eigenen Webseite), Intranet/Internet fähig, keine Installationen auf dem
Client notwendig (nur Internet Browser),

Nur Internet Browser? Soll ich Dir was sagen? Ich halte solche Apps Stand
heute für unbedienbar. Nicht wg. der Geschwindigkeit, das geht mit AJAX
ganz gut, aber wg. der begrenzten Widget-Sets. Da nehme ich dann doch
lieber Delphi, VB, C#, Java oder sowas.

Post by Monsieur Ibrahim
keine besonderen
Clientanforderungen, kein unötiges MS Gedöhns, das nach max. 5 Jahren
nicht mehr supported wird [...]

Ja, alles richtig, haben wir auch schon drüber nachgedacht, das hat seinen
Reiz. Thin Clients und so, prima auch remote machbar, hört sich supergut
an. Aber wie gesagt - s.o.

Danke & Gruß,
Ekki

[Peter Fleischer]

Post by Ekki Plicht
Ja, alles richtig, haben wir auch schon drüber nachgedacht, das hat
seinen Reiz. Thin Clients und so, prima auch remote machbar, hört
sich supergut an. Aber wie gesagt - s.o.

Hi Ekki,
hast du dir schon mal VB.NET mit ClickOnce angeschaut?
Client-Windows-Anwendungen, die immer auf dem aktuellen Stand sind und damit
einen gut beherrschbaren Übergang ermöglichen.

[Ekki Plicht]

Post by Kroni

Post by Ekki Plicht
4) Vorhandenes Opensource Projekt nehmen und sich dranhängen, z.B. CAO. Da
könnte man am Entwicklungsprozess teilnehmen, eigene Entwicklungen
einfliessen lassen bzw. einen eigenen Fork bauen. Hohe Flexibilität und man
fängt nicht bei Null an.

Ist eine Möglichkeit.
Ich glaube die hängen an einer Firebird oder MySQL Datenbank.
Besser wäre da vielleicht für die Zukunft auf SQL Server zu setzen.

MySQL.
Wieso? Geht MySQL morgen den Bach runter?

Post by Kroni
Und umbauen ist auch oftmals aufwendiger als gleich
was neues zu machen.
Hängt davon ab wie spezifisch und umfangreich eure Sachen sind.

ACK. Den Aufwand muss ich noch versuchen abzuschätzen.

Danke & Gruß,
Ekki

[Bodo Rzany]

Post by Ekki Plicht

Post by Kroni
Ich glaube die hängen an einer Firebird oder MySQL Datenbank.
Besser wäre da vielleicht für die Zukunft auf SQL Server zu setzen.

MySQL.
Wieso? Geht MySQL morgen den Bach runter?

Ich vermute, Kroni promoted nur SQL Server oder lebt davon.

Ich habe seinerzeit PostgreSQL für eine Entwickler-Datenbank
(CAD und Dokumentation) eingesetzt. Nur um noch eine in meinen
Augen sehr beachtenswerte Alternative zu MySQL anzuführen (PG
scheint mir für große DBs besser zu skalieren).

Gruß
Bodo

[Peter Fleischer]

Post by Bodo Rzany

Post by Ekki Plicht

Post by Kroni
Ich glaube die hängen an einer Firebird oder MySQL Datenbank.
Besser wäre da vielleicht für die Zukunft auf SQL Server zu setzen.

MySQL.
Wieso? Geht MySQL morgen den Bach runter?

Ich vermute, Kroni promoted nur SQL Server oder lebt davon.

Hi Bodo,
SQL Server 2005 Express ist kostenlos. Wie soll man davon leben? Und das
Limit von 4 GB Daten muss man mit mit 20 MA erst einmal erreichen:-)

Post by Bodo Rzany
Ich habe seinerzeit PostgreSQL für eine Entwickler-Datenbank
(CAD und Dokumentation) eingesetzt. Nur um noch eine in meinen
Augen sehr beachtenswerte Alternative zu MySQL anzuführen (PG
scheint mir für große DBs besser zu skalieren).

PostgreSQL meinst du nicht wirklich ernsthaft?

[Bodo Rzany]

Hallo Peter,

Post by Peter Fleischer
SQL Server 2005 Express ist kostenlos. Wie soll man davon leben? Und das
Limit von 4 GB Daten muss man mit mit 20 MA erst einmal erreichen:-)

Wie ich, zugegebenermaßen gerade eben erst, lese, ist das Ding die
kostenlose Schnupperversion der großen Microsoft DB-Maschine. Eben
kostenlos, aber nicht offen. :-(

Post by Peter Fleischer

Post by Bodo Rzany
Ich habe seinerzeit PostgreSQL für eine Entwickler-Datenbank
(CAD und Dokumentation) eingesetzt. Nur um noch eine in meinen
Augen sehr beachtenswerte Alternative zu MySQL anzuführen (PG
scheint mir für große DBs besser zu skalieren).

PostgreSQL meinst du nicht wirklich ernsthaft?

Was stört Dich an PostgreSQL? Daß es offen ist, 32 TeraByte Tabellen
kann (bei unlimitierter DB-Größe) und aus der Forschung kommt? Für
mich war es seinerzeit das non plus ultra, auch wenn ich damals noch
Trigger in C programmieren musste. Heute ist das integriert, aber
damals war mir die Freiheit den (etwas) höheren Aufwand wert. Für
mich gibt es bis heute keine sinnvolle Alternative dazu.

Ich wollte nur eine Anregung geben. Für weitergehende Diskussionen
mit dem Hintergrundthema closed source versus open source bin ich
nicht der richtige Partner, zumal ich mein Geld nun wirklich nicht
mit Software verdiene.

Gruß
Bodo

[Lutz Schulze]

Post by Bodo Rzany

Post by Peter Fleischer
PostgreSQL meinst du nicht wirklich ernsthaft?

Was stört Dich an PostgreSQL?

Es ist nicht von MS ;-)

Lutz

[Bodo Rzany]

Post by Lutz Schulze

Post by Bodo Rzany

Post by Peter Fleischer
PostgreSQL meinst du nicht wirklich ernsthaft?

Was stört Dich an PostgreSQL?

Es ist nicht von MS ;-)

Jetzt verstehe ich... ;-<

Bodo

[Aleks A.-Lessmann]

Post by Lutz Schulze

Post by Bodo Rzany

Post by Peter Fleischer
PostgreSQL meinst du nicht wirklich ernsthaft?

Was stört Dich an PostgreSQL?

Es ist nicht von MS ;-)

Was der MSCE nicht kennt, das frisst er nicht?

Oder wie meinen?
Aleks

[Lutz Schulze]

Post by Aleks A.-Lessmann

Post by Lutz Schulze

Post by Bodo Rzany

Post by Peter Fleischer
PostgreSQL meinst du nicht wirklich ernsthaft?

Was stört Dich an PostgreSQL?

Es ist nicht von MS ;-)

Was der MSCE nicht kennt, das frisst er nicht?
Oder wie meinen?
Aleks

So in der Art. MS-Kurse vermitteln oft eine etwas eingeschränkte Weltsicht.
So wie Kurse von anderen Herstellern auch.

Im Netzwerkbereich habe ich meinen Mitstreitern immer gesagt: 'wir lernen
erst einmal allgemein die Technik nach Standards, dann können wir schauen
(und ganz nebenbei auch mal kritisch bewerten) wie die einzelnen Hersteller
das umgesetzt haben'.

Lutz

[Aleks A.-Lessmann]

Post by Lutz Schulze
So in der Art. MS-Kurse vermitteln oft eine etwas eingeschränkte Weltsicht.
So wie Kurse von anderen Herstellern auch.

Dann haben wir das selbe gedacht.

Alles klar
Aleks

[Peter Fleischer]

Post by Bodo Rzany
Wie ich, zugegebenermaßen gerade eben erst, lese, ist das Ding die
kostenlose Schnupperversion der großen Microsoft DB-Maschine. Eben
kostenlos, aber nicht offen. :-(

Hi Bodo,
was nutzt eine offene Datenbank? Und wozu brauchst ein Anwender, der gerade
von dBase umsteigt, Dinge, die in den kostenlosen Versionen des SQL Servers,
Oracle oder DB2 nicht vorhanden ist? Wozu braucht der OP z.B. einen Service
Broker, der in der kostenlosen Version des SQL Servers 2005 nicht enthalten
ist?

Post by Bodo Rzany

Post by Peter Fleischer

Post by Bodo Rzany
Ich habe seinerzeit PostgreSQL für eine Entwickler-Datenbank
(CAD und Dokumentation) eingesetzt. Nur um noch eine in meinen
Augen sehr beachtenswerte Alternative zu MySQL anzuführen (PG
scheint mir für große DBs besser zu skalieren).

PostgreSQL meinst du nicht wirklich ernsthaft?

Was stört Dich an PostgreSQL?

Z.B. fehlende Funktionalitäten wie fehlende CLR integration und vor allem
die vielen Fragen genervter Programmentwickler, die einfache z.B. mit der
DB2 zu lösende Aufgaben mit PostgreSQL nicht ode rnur umständlich lösen
können. Leider fehlen mir dazu die tieferen Kenntnisse, um das genau
einschätzen zu können.

Post by Bodo Rzany
Daß es offen ist, 32 TeraByte Tabellen
kann (bei unlimitierter DB-Größe) und aus der Forschung kommt?

Zeig mal eine Firma mit 20 MA, die zu einem Sachverhalt (z.B. Adressdaten)
mehr 4 GB Daten hat. Problematisch wird die Begrenzung lediglich, wenn der
Anwender in der Datenbank Bilder speichern will, beispielsweise eingescannte
Dokumente.

Post by Bodo Rzany
Für
mich war es seinerzeit das non plus ultra, auch wenn ich damals noch
Trigger in C programmieren musste. Heute ist das integriert, aber
damals war mir die Freiheit den (etwas) höheren Aufwand wert. Für
mich gibt es bis heute keine sinnvolle Alternative dazu.

Dann schau dir mal die Integration von .NET z.B. bei DB2 an, die
Management-Oberfläche, die Möglichkeiten der Reporting Services beim SQL
Server.

Post by Bodo Rzany
Ich wollte nur eine Anregung geben. Für weitergehende Diskussionen
mit dem Hintergrundthema closed source versus open source bin ich
nicht der richtige Partner, zumal ich mein Geld nun wirklich nicht
mit Software verdiene.

OK

[Bodo Rzany]

Hallo Peter,

so ganz unkommentiert kann ich einige Deiner Anmerkungen zu Postgres
nun doch nicht lassen, weil manche Leser durch sie einen falschen
bekommen können.

Post by Peter Fleischer
was nutzt eine offene Datenbank?

Sicherheit, nicht 3 Jahre nach erledigter Umstellung vom SW-Hersteller
sitzengelassen zu werden?
Für mich war schon immer die Möglichkeit, mir bei Problemen selbst
helfen zu können, sehr wichtig. Aber das mögen Andere anders sehen.

Post by Peter Fleischer
Und wozu brauchst ein Anwender, der gerade
von dBase umsteigt, Dinge, die in den kostenlosen Versionen des SQL Servers,
Oracle oder DB2 nicht vorhanden ist? Wozu braucht der OP z.B. einen Service
Broker, der in der kostenlosen Version des SQL Servers 2005 nicht enthalten
ist?

Das habe ich, auch nach mehrmaligem Lesen, leider nicht verstanden. Oder
meinst Du, daß Dinge, die in SQL Server nicht vorhanden sind, sowieso
niemand braucht (oder besser wohl: brauchen darf)? Das wäre dann aber
Micosoft schon sehr weit in den Axxxx gekrochen...

Post by Peter Fleischer

Post by Bodo Rzany
Was stört Dich an PostgreSQL?

Z.B. fehlende Funktionalitäten wie fehlende CLR integration und vor allem
die vielen Fragen genervter Programmentwickler, die einfache z.B. mit der
DB2 zu lösende Aufgaben mit PostgreSQL nicht ode rnur umständlich lösen
können. Leider fehlen mir dazu die tieferen Kenntnisse, um das genau
einschätzen zu können.

CLR Integration sagt mir nichts, aber die vielen Fragen von
"Programmentwicklern", die Dokumentationen nicht lesen oder nicht
verstehen wollen, "weil das ja Alles intuitiv ist bzw. sein soll",
kenne ich sehr wohl. Mit solchen Leuten gebe ich mich schon lange
nicht mehr ab.

Seit etwa 6 Jahren habe ich mich mit Postgres nicht mehr beschäftigt,
so daß ich nicht weiß, was für Dich heute mit Postgres und den damit
bereitgestellten Werkzeugen nicht lösbar sein sollte. Damals ging
alles, und ich kann mir allerdings nicht vorstellen, daß seitdem
Funktionalität entfernt worden ist. Wohl eher im Gegenteil.

Post by Peter Fleischer
Dann schau dir mal die Integration von .NET z.B. bei DB2 an, die
Management-Oberfläche, die Möglichkeiten der Reporting Services beim SQL
Server.

Weil mir die Microsoft-Basis fehlt, beobachte ich etwas die Bemühungen
um Mono. Mir gefällt nicht, daß damit intelligente Leute ihre Zeit
vertun. Aber das ist nur meine unmaßgebliche persönliche Meinung zu
diesem Thema.

Grüße
Bodo

[Peter Fleischer]

Post by Bodo Rzany
Hallo Peter,
so ganz unkommentiert kann ich einige Deiner Anmerkungen zu Postgres
nun doch nicht lassen, weil manche Leser durch sie einen falschen
bekommen können.

Post by Peter Fleischer
was nutzt eine offene Datenbank?

Sicherheit, nicht 3 Jahre nach erledigter Umstellung vom SW-Hersteller
sitzengelassen zu werden?

Hi Bodo,
der kostenlose SQL Server 2005 Express ist die Weiterentwicklung der ersten
Sybase-Versionen aus dem Jahre 1989. Das sind etwas mehr als 3 Jahre :-) Die
Implementierung der SQL-Stabdards erlaubt außerdem einen Übergang zu anderen
Datenbanksystem, die SQl verstehen.

Post by Bodo Rzany
Für mich war schon immer die Möglichkeit, mir bei Problemen selbst
helfen zu können, sehr wichtig. Aber das mögen Andere anders sehen.

Alles selbst zu machen, mag sehr interessant sein. Welcher AG oder
Arbeitgeber ist schon bereit, diesen Aufwand zu bezahlen.

Post by Bodo Rzany

Post by Peter Fleischer
Und wozu brauchst ein Anwender, der gerade
von dBase umsteigt, Dinge, die in den kostenlosen Versionen des SQL
Servers, Oracle oder DB2 nicht vorhanden ist? Wozu braucht der OP
z.B. einen Service Broker, der in der kostenlosen Version des SQL
Servers 2005 nicht enthalten ist?

Das habe ich, auch nach mehrmaligem Lesen, leider nicht verstanden.

Ich meine, dass die kostenpflichtigen Vollversionen einen Funktionsumfang
bieten, den ein Anwender, der bisher nur mit dBase gearbeitet hat, vorerst
nicht benötigt und schon mit dem Funktionsumfang der kostenlosen Ausgaben
einen gewaltigen Fortschritt erzielen kann.

Post by Bodo Rzany
Oder meinst Du, daß Dinge, die in SQL Server nicht vorhanden sind,
sowieso niemand braucht (oder besser wohl: brauchen darf)? Das wäre
dann aber Micosoft schon sehr weit in den Axxxx gekrochen...

Schau dir mal an, was in der Express Edition des MS SQL Servers 2005 nicht
unterstützt wird:

http://www.zdnet.de/builder/architect/0,39023548,39140344-2,00.htm

Post by Bodo Rzany

Post by Peter Fleischer

Post by Bodo Rzany
Was stört Dich an PostgreSQL?

Z.B. fehlende Funktionalitäten wie fehlende CLR integration und vor
allem die vielen Fragen genervter Programmentwickler, die einfache
z.B. mit der DB2 zu lösende Aufgaben mit PostgreSQL nicht ode rnur
umständlich lösen können. Leider fehlen mir dazu die tieferen
Kenntnisse, um das genau einschätzen zu können.

CLR Integration sagt mir nichts,

Unterstützung der Common Language Runtime - d.h., man kann im
Datenbankserver seine eigenen Programme mit der gleichen Programmiersprache
und der gleichen Laufzeitungebung wie die eigentliche Anwendung schreiben,
um z.B. Programme als Prozeduren laufen zu lassen, Programme als Funktionen
im SQL aufzurufen oder eigene (nutzerdefinierte) Feldtypen zu erstellen, die
SQL bzw. der Datenbankserver nicht kennt.

Die Bemerkung mit der CLR-Unterstützung war nur ein Beispiel. Mit
Report-Unterstützung könnte man fortsetzen.

Post by Bodo Rzany
aber die vielen Fragen von
"Programmentwicklern", die Dokumentationen nicht lesen oder nicht
verstehen wollen, "weil das ja Alles intuitiv ist bzw. sein soll",
kenne ich sehr wohl.

So etwas trifft man leider immer wieder. Aber mal ehrlich, einem selbst kann
das auch schnell passieren, wenn man seine Suchanfrage an die Dokumentation
nicht ausreichend qualifiziert formulieren kann.

Post by Bodo Rzany
Mit solchen Leuten gebe ich mich schon lange
nicht mehr ab.
Seit etwa 6 Jahren habe ich mich mit Postgres nicht mehr beschäftigt,
so daß ich nicht weiß, was für Dich heute mit Postgres und den damit
bereitgestellten Werkzeugen nicht lösbar sein sollte.

Anstelle der CLR-Unterstützung bietet PostgresSQL eine eigene Sprache
(Pl/PgSQL) auf prozeduraler Ebene, die in die eigentliche Anwendung nicht
integrierbar ist. Das bedeutet zusätzlicher Aufwand sowohl beim
Programmieren, bei der Qualifikation, beim Test und kann sich damit sehr
schnell auf die Qulität und Performance der Lösung auswirken.

Post by Bodo Rzany
Damals ging
alles, und ich kann mir allerdings nicht vorstellen, daß seitdem
Funktionalität entfernt worden ist. Wohl eher im Gegenteil.

Es ist schon eine ganze Menge dazugekommen, hinkt aber hinter den 3 Großen
hinterher.

Post by Bodo Rzany

Post by Peter Fleischer
Dann schau dir mal die Integration von .NET z.B. bei DB2 an, die
Management-Oberfläche, die Möglichkeiten der Reporting Services beim
SQL Server.

Weil mir die Microsoft-Basis fehlt, beobachte ich etwas die Bemühungen
um Mono. Mir gefällt nicht, daß damit intelligente Leute ihre Zeit
vertun.

Das Problem hast du aber bei vielen "open source"-Projekten. Da kann man
geteilter Meinung sein. Solche Projekte können aber intensiv andere
kommerzielle Lösungen befruchten.

Post by Bodo Rzany
Aber das ist nur meine unmaßgebliche persönliche Meinung zu
diesem Thema.

[Ralf Zschemisch]

Post by Peter Fleischer

Ich habe seinerzeit PostgreSQL für eine Entwickler-Datenbank (CAD und
Dokumentation) eingesetzt. Nur um noch eine in meinen Augen sehr
beachtenswerte Alternative zu MySQL anzuführen (PG scheint mir für
große DBs besser zu skalieren).

PostgreSQL meinst du nicht wirklich ernsthaft?

Doch - eigentlich ist dies eine wunderbare kostenfreie
alternative zu MySQL.

Und die WaWi dazu gibt es hier
http://pgfakt.de/

Bei kostenpflichtigen Versionen, greift man halt auf
Entwickler zurück, die mit einer "klicki_bunten_welt"
etwas zusammen "hauen" können. Ergo DB2 und co.

Aber so etwas würde ich nicht ernsthaft empfehlen.

cu


r23

[Peter Fleischer]

Post by Ralf Zschemisch

Post by Peter Fleischer
PostgreSQL meinst du nicht wirklich ernsthaft?

Doch - eigentlich ist dies eine wunderbare kostenfreie
alternative zu MySQL.
Und die WaWi dazu gibt es hier
http://pgfakt.de/

Hi Ralf,
bezogen auf MySQL hast du Recht; bezogen aber auf die kostenfreien Großen
solltest du dich nochmals informieren, z.B.:
http://www.zdnet.de/builder/print_this.htm?pid=39140387-20000202c (etwas
älter, mySQL-lastig)
http://postgresql.de/postgresql_outline.html (aktuelle Funktionen)
http://www.zdnet.de/builder/architect/0,39023548,39140344-2,00.htm

Post by Ralf Zschemisch
Bei kostenpflichtigen Versionen, greift man halt auf
Entwickler zurück, die mit einer "klicki_bunten_welt"
etwas zusammen "hauen" können. Ergo DB2 und co.

MS SQL SERVER Express 2005 ist aber genau wie die MSDE (MS SQL SERVER 2000)
kostenlos.

Post by Ralf Zschemisch
Aber so etwas würde ich nicht ernsthaft empfehlen.

Einem Marktführer sollte man also nie vertrauen?

[Hans- Peter Walther]

Post by Peter Fleischer
Einem Marktführer sollte man also nie vertrauen?

Korrektur: MS sollte man niemals alleinig vertrauen.
mfg
HPW

[Peter Fleischer]

Post by Hans- Peter Walther

Post by Peter Fleischer
Einem Marktführer sollte man also nie vertrauen?

Korrektur: MS sollte man niemals alleinig vertrauen.

Hi Hans-Peter,
dann nimm den anderen Großen - Oracle Database XE :

http://www.pro-linux.de/news/2006/9357.html

http://www.oracle.com/technology/products/database/xe/pdf/dbxe_faq.pdf

[Bodo Rzany]

Post by Peter Fleischer
http://www.pro-linux.de/news/2006/9357.html

Hmm, mein aktuelles 64bit-Linux wird gerade wieder nicht unterstützt.
Sollte ich deshalb etwa mein schnelles System wieder "downgraden"?

Ich frage mich wirklich, warum Du hier gegen open source zu Felde
ziehst. Wir (oder war's nur ich) haben einem Fragenden eine weitere
Alternative genannt, und Du ziehst daraufhin die ideologische
Klatsche hervor. Warum? Hast Du einfach nur zuviel Zeit? Dein
großes Wissen um Postgres kann ja wohl nicht der Grund sein, wie
Du gestern selbst gesagt hast.

Bodo

[Lutz Schulze]

Post by Bodo Rzany
Ich frage mich wirklich, warum Du hier gegen open source zu Felde
ziehst. Wir (oder war's nur ich) haben einem Fragenden eine weitere
Alternative genannt, und Du ziehst daraufhin die ideologische
Klatsche hervor. Warum? Hast Du einfach nur zuviel Zeit? Dein
großes Wissen um Postgres kann ja wohl nicht der Grund sein, wie
Du gestern selbst gesagt hast.

Ein Reflex, vermute ich mal. Und ausserdem nicht vom Marktführer ;-)

Lutz

[Hans- Peter Walther]

Post by Bodo Rzany

Post by Peter Fleischer
http://www.pro-linux.de/news/2006/9357.html

Hmm, mein aktuelles 64bit-Linux wird gerade wieder nicht
unterstützt. Sollte ich deshalb etwa mein schnelles System
wieder "downgraden"?

Naja, meine SuSE 10.0 scheint ja unterstützt zu werden. Aber ob
ich deswegen jetzt mein lx- office von Postgres auf Oracle
umstricken sollte?
;-)
Das JS- Menue darin habe ich übrigens abgeschaltet- es gibt eine
CSS- Alternative.

Post by Bodo Rzany
Ich frage mich wirklich, warum Du hier gegen open source zu
Felde ziehst. Wir (oder war's nur ich) haben einem Fragenden
eine weitere Alternative genannt, und Du ziehst daraufhin die
ideologische Klatsche hervor. Warum? Hast Du einfach nur
zuviel Zeit? Dein großes Wissen um Postgres kann ja wohl nicht
der Grund sein, wie Du gestern selbst gesagt hast.

Wenn ich dann allerdings in o.a. Artikel von "lizenzrechtlichen
Feinheiten" lese, kommt mir das Ko....
Fällt aus. Mags nicht mal lesen.
mfg
HPW

[Bodo Rzany]

Post by Hans- Peter Walther

Post by Bodo Rzany

Post by Peter Fleischer
http://www.pro-linux.de/news/2006/9357.html

Hmm, mein aktuelles 64bit-Linux wird gerade wieder nicht
unterstützt. Sollte ich deshalb etwa mein schnelles System
wieder "downgraden"?

Naja, meine SuSE 10.0 scheint ja unterstützt zu werden. Aber ob
ich deswegen jetzt mein lx- office von Postgres auf Oracle
umstricken sollte?
;-)

Peter Fleischer würde Dich dann sicher promoten. Und so, wie er
sich hier engagiert, könnte das sogar für Dich den ganz großen
Reibach bedeuten. ;-)

Post by Hans- Peter Walther
Wenn ich dann allerdings in o.a. Artikel von "lizenzrechtlichen
Feinheiten" lese, kommt mir das Ko....

Einige proprietäre und dabei für mich durchaus "unternehmenskritische"
Software (insbesondere CAD und E-CAD) setze auch ich ein (natürlich
nur, was für Linux angeboten wird). Mit den Lizenzen habe ich solange
kein Problem, solange es da keine Aktivierungs- oder Update-Pflichten
gibt.

Grüße
Bodo

[Matthias Frey]

Post by Ekki Plicht

Post by Kroni

Post by Ekki Plicht
4) Vorhandenes Opensource Projekt nehmen und sich dranhängen, z.B. CAO. Da
könnte man am Entwicklungsprozess teilnehmen, eigene Entwicklungen
einfliessen lassen bzw. einen eigenen Fork bauen. Hohe Flexibilität und man
fängt nicht bei Null an.

Ist eine Möglichkeit.
Ich glaube die hängen an einer Firebird oder MySQL Datenbank.
Besser wäre da vielleicht für die Zukunft auf SQL Server zu setzen.

MySQL.
Wieso? Geht MySQL morgen den Bach runter?

Also Leute ...
Die Wahl eine konkreten Datenbank macht erst Sinn, wenn das Konzept
steht. Wenn bisher dbase zum Einsatz kam, dürfte das jede andere
aktuelle Datenbank auch können.
Viele Entwicklungssysteme unterstützen eh mehrere Datenbanken.

Post by Ekki Plicht

Post by Kroni
Und umbauen ist auch oftmals aufwendiger als gleich
was neues zu machen.
Hängt davon ab wie spezifisch und umfangreich eure Sachen sind.

ACK. Den Aufwand muss ich noch versuchen abzuschätzen.

Das ist eher die Frage.
Ich halte (ohne das ich Erfahrung habe) einen kompletten Umstieg
an einem Tag für recht riskant. So wie ich raushöre sind die Abläufe kaum
dokumentiert und irgendetwas vergisst man sicher.

Ein Vorschlag noch.
Neue Entwicklung Schritt für Schritt mit einem Entwicklungssystem,
das auch noch dbase unterstützt (z.B.) Delphi. Die neuen Programm
arbeiten dann noch mit den alten Daten.
Wenn dann alle Funktionen neu sind, die Datenbank wechseln.


Und noch ein Gedanke...
Vielleicht auch ein Mix aus Standardprogramm und individueller
Programmierung was. Ich kenne einen, der hat das früher mal gemacht.
Welche Software das war weiß ich nicht mehr, könnte aber nachfragen.

Post by Ekki Plicht
Danke & Gruß,
Ekki

Grüße
Matthias

[Heinrich Butschal]

...

Post by Matthias Frey

Post by Ekki Plicht

Post by Kroni
Ich glaube die hängen an einer Firebird oder MySQL Datenbank.
Besser wäre da vielleicht für die Zukunft auf SQL Server zu setzen.

MySQL.
Wieso? Geht MySQL morgen den Bach runter?

Also Leute ...
Die Wahl eine konkreten Datenbank macht erst Sinn, wenn das Konzept
steht. Wenn bisher dbase zum Einsatz kam, dürfte das jede andere
aktuelle Datenbank auch können.
Viele Entwicklungssysteme unterstützen eh mehrere Datenbanken.

Völlig korrekt. Dazu gibt es ODBC Treiber.

Post by Matthias Frey

Post by Ekki Plicht

Post by Kroni
Und umbauen ist auch oftmals aufwendiger als gleich
was neues zu machen.
Hängt davon ab wie spezifisch und umfangreich eure Sachen sind.

ACK. Den Aufwand muss ich noch versuchen abzuschätzen.

Das ist eher die Frage.
Ich halte (ohne das ich Erfahrung habe) einen kompletten Umstieg
an einem Tag für recht riskant. So wie ich raushöre sind die Abläufe kaum
dokumentiert und irgendetwas vergisst man sicher.

Stimmt auch bei gut dokumentierten Projekten und ich habe darin Erfahrung.
Wozu ohne Not Risiken anhäufen?

Post by Matthias Frey
Ein Vorschlag noch.
Neue Entwicklung Schritt für Schritt mit einem Entwicklungssystem,
das auch noch dbase unterstützt (z.B.) Delphi. Die neuen Programm
arbeiten dann noch mit den alten Daten.
Wenn dann alle Funktionen neu sind, die Datenbank wechseln.

Exakt, kann aber auch eine andere Entwicklungsumgebung sein. Mein Vorschlag
dotnet nur deshalb, weil das viele können und in Zukunft soll ja im Haus
weiterentwickelt werden.


Mit freundlichem Gruß,
Heinrich Butschal

[Frank Sertic]

Post by Ekki Plicht
Tag.
4) Vorhandenes Opensource Projekt nehmen und sich dranhängen, z.B. CAO. Da
könnte man am Entwicklungsprozess teilnehmen, eigene Entwicklungen
einfliessen lassen bzw. einen eigenen Fork bauen. Hohe Flexibilität und man
fängt nicht bei Null an.

Etwas besser
Lx-Office CRM
Lx-Office ERP inklusive DATEV und ELSTER
http://www.lx-office.org

Gruss Frank

[Ekki Plicht]

Post by Frank Sertic

Post by Ekki Plicht
Tag.
4) Vorhandenes Opensource Projekt nehmen und sich dranhängen, z.B. CAO. Da
könnte man am Entwicklungsprozess teilnehmen, eigene Entwicklungen
einfliessen lassen bzw. einen eigenen Fork bauen. Hohe Flexibilität und man
fängt nicht bei Null an.

Etwas besser
Lx-Office CRM
Lx-Office ERP inklusive DATEV und ELSTER
http://www.lx-office.org

Ok, danke, werden wir uns angucken.

Gruß,
Ekki