Hi, Delpher,

ich denke, dass ich eine Datenbank von BDE auf ADO umstricken werde. Kann mir jemand sagen, was sich dabei im Wesentlichen ändert, bzw. was das geeignete Vorgehen im Groben/Feinen ist?

Danke für Unterstützung,
Detlef

Für welche Datenbanken willst du das machen? Für Access und den MS SQL Server ist ADO(Express) das beste. Für alle andere DB's kommt man vom Regen in die Traufe. Hier sollte man wenn man nichts ausgeben will Zeos nehmen oder angepaßte Kompos z.B. von Core Labs.

Hi, Bernhard,

auf keinen Fall Access!!

Aktuell ist es eigentlich eine alte DBase-Anwendung, aber ich will auch möglichst vielseitig mich auf andere DB-Systeme einstellen können. Mit Interbase habe ich auch schon gute Erfahrungen gemacht und für mich eigentlich erste Wahl. Was wäre denn so die zweite Wahl nach Interbase?

Danke für weitere Ideen,
Detlef

D. Annies hat folgendes geschrieben:

auf keinen Fall Access!!

Access ist für Einzelplatzanwendungen wirklich gut, also weg mit den Vorurteilen.

D. Annies hat folgendes geschrieben:

Aktuell ist es eigentlich eine alte DBase-Anwendung,

Auch nicht besser als Access.

D. Annies hat folgendes geschrieben:

aber ich will auch möglichst vielseitig mich auf andere DB-Systeme einstellen können. Mit Interbase habe ich auch schon gute Erfahrungen gemacht und für mich eigentlich erste Wahl. Was wäre denn so die zweite Wahl nach Interbase?

Such mal nach den bekannten DB-Diskussionen. FB/MSDE/PostgreSQL etc. sind da noch zu erwähnen.

alzaimar hat folgendes geschrieben:

D. Annies hat folgendes geschrieben: auf keinen Fall Access!! Access ist für Einzelplatzanwendungen wirklich gut, also weg mit den Vorurteilen. D. Annies hat folgendes geschrieben: Aktuell ist es eigentlich eine alte DBase-Anwendung, Auch nicht besser als Access.

Dem muß ich vehement widersprechen...ich hab jahrelang mit Access97 gearbeitet und das war ok, auch ein Kollege hat damit was ganz passables hingebastelt, das auch Netzwerkfähig war. Er hat nicht programmiert, war auch kein ITler, sondern Arbeitsvorbereiter...das hat funktioniert

Neuerdings habe ich Kontakt mit Access 2003 und irgendwie stimmt da was nicht mit.

Ich habe z.B. ein Buchungsformular gemacht und gelegentlich zeigt das Ding gewisse Felddaten nicht an, obwohl sie im Feld drin stehen.
OK, das betrifft nur die Oberfläche, hat nichts mit der Datenbank selbst zu tun.
Aber ich habe letztens eine Abfrage gemacht, dafür benutz ich Access sowieso hauptsächlich, als Query-Builder und die Ergebnismenge war nicht richtig, obwohl meiner Meinung nach das SQL richtig war.

Ganz toll fand ich letztens, ich mußte Absatzzahlen so hinbiegen, daß man Jahre gegenüberstellen kann, weil der Progger dieses Programms versäumt hat, den Sätzen auch ein Buchungsjahr mitzugeben und sich die Daten darum in separaten Datenbanken befinden, wollte ich das Ganze verlinkt über jeweilige Unterabfragen, die da ein Feld Jahr kreieren mit UNION zusammenfügen.
Mal abgesehen davon, daß mir Access gelegentlich die Ausgabe des Feldes Buchungsjahr wieder rausgeschmissen hat, motzte Karlchen Klammer wegen dem UNION dann rum, ich hätte einen Fehler beim Statement bei FROM

also was soll daran falsch sein

SELECT * FROM Tabelle1
UNION [ALL]
SELECT * FROM Tabelle2

alternativ hab ich es ohne all probiert, nix zu machen...habs dann letztendlich statisch gemacht.
Heißt Tabelle 1 gemacht, Tabelle 2 dann per Anfügeabfrage hinzugefügt.

Nix da Vorurteile...ich hab mit Access schon die krummsten Sachen erlebt.

Ganz lieb war da auch ein Fehler in Access 2...ich hatte damals das Feld Kundennr als int und zunächst die Daten aus einer DBF Datei importiert...paar Jahre später hab ich die dann aus einer CSV-Datei importiert.
Dann mußte ich einen Bericht machen, der die Umsätze gruppiert und war ziemlich verdutzt, als die meisten Kunden doppelt auftauchten.
Des Rätsels Lösung...int in Access war nicht wirklich int, die KundenNr in den DBF waren Double, das hat sich Access gemerkt, obwohl KundenNr definitiv als int deklariert war
Ich hab den ganzen Schlamassel dann in ein CSV exportiert, dann wieder importiert, dann paßte es.

Access trau ich nicht mehr wirklich...allenfalls Access97 weil damit hab ich jahrelang nie Probleme gehabt, und dabei eigentlich schon ein paar mal den Nippel hinten durch die Lasche gezogen

Jedenfalls, MySQL wäre meine erste Wahl, wenns nicht darum geht das Programm zu verkaufen...leider ist ja die Lizenzpolitik von MySQL etwas chaotisch, bis kostspielig.

Gruß

Aga

Ich meinte eher: Access in Verbindung mit ADO. Gut gut. Wie war die Eingangsfrage nochmal? Ach ja, von BDE nach ADO (o.ä.) und eventuell weg von Access.

Ich habe mal einen BDE->ADO Converter geschrieben, der 90% der notwendigen Änderungen vornimmt (TDatabase->TADOConnection, TTable->TADOTable etc.), die DFM umfriemelt, sowie im Sourcecode einige Anpassungen macht. Den Rest habe ich bei einem 50.000 Zeilen Programm in 3-4 Std. hinbekommen. (Mit anderen Worten: Nicht so schwer).

Hi, Leute,

seehr interessant bisher - und ich habe herrlich gelacht (obwohl das sicher nicht witzig war, nur über die Art, es aufzuschreiben!) über Access!

Danke, bisher!
Detlef

Hi

naja, witzig war es tatsächlich nicht, kanns auch nicht sein, wenn man einen Abgabetermin hat und halb am Verzweifeln ist...nachher ist es doch witzig, wenn einem eingefallen ist, daß man die Importquelle vor Jahren mal verändert hat, dann ist die Lösung des Problems nur noch ein paar Minuten weit entfernt.

Man lacht dann sozusagen aus dem Gefühl der Erleichterung heraus

Aber back to Topic...muß es denn unbedingt ADO sein ?...Ich stehe den Machwerken von Microsoft, was Datenbanken angeht, sehr skeptisch gegenüber...ok, hab mit ADO nicht gearbeitet, kann mich daher nicht lästerlich äußern.
Trotzdem, Microsoft läßt Dinge zu, die dann an irgendeiner Ecke Probleme verursachen.

Geht wieder um Access, was Du ja sowieso nicht willst, aber wenn ich mir hier manchmal die eine oder andere Abfrage anschau, dann wird mir schlecht, Sonderzeichen in Feldnamen
Leerzeichen hab ich glaub ich auch schon mal gesehen.

Microsoftprodukte verleiten eben dazu, solchen, in meinen Augen Dummfug zu machen...die weitere Konsequenz ist, daß die Portabilität auf andere DBMS damit sozusagen völlig dahin ist, bzw. man macht es dann wie Alzaimar...zig mal die F9 Taste drücken

Vor fast einem Jahr hab ich eine unangenehme Entscheidung treffen müssen....MySQL und ODBC haben überhaupt nicht funktioniert, hab mir dann die CoreLab Sache angeschaut...und habe mich nach ein paar Tests dafür entschieden, wohlwissend, daß ich damit den Pfad der Tugend verlasse...der heißt...die Abstraktionsschicht 'Datenbankzugriff gekapselt' gibt es für mich nicht mehr...wollt ich jetzt auf ein anderes System migrieren, wär das schon mit Aufwand verbunden...andererseits überzeugt mich einfach die Performance.

Die sogenannten Alleskönner, wie ADO können nicht optimal sein.

Was auch immer Du machst, bei SQL halt Dich an ANSI92 und bei der Vergabe von Feldnamen, oder Tabellnnamen...keine Umlaute, keine Sonderzeichen.

Ach da hab ich noch was, da war ein Progger bei uns, der wollte eine Oracle-DB installieren, der ist bald irre geworden, ich auch, weil ich zugeguckt habe...der hat bis nach Karlsruhe...Zentrale angerufen, wieso er das nicht installieren kann...dann hab ich ihm gesagt, lassen Sie mal den Unterstrich im Datenbanknamen weg...der hat mich angeguckt, als wär ich geisteskrank und meinte, das ist nicht Ihr Ernst....Doch, sag ich, ist mein Ernst...ach na ja, ohne Unterstrich funktionierte das tadellos

Morgen kann ich noch nen Link nachreichen von einem Access-Programmierer...die Sachen die der drauf hat, beziehen sich hauptsächlich auf 2, sind auch sehr komisch

Gruß

Aga

Hi, Aga,

Alter, mir fehlen die Worte!!!

Bis auf weiteres ...

da kann man ja fast das Thema vergessen!!

Hier der Link

www.breitenbuecher.d...infobase/ibframe.htm

bezieht sich zwar überwiegend auf Access 2.0, ist aber sehr lustig, vor allem die Datums- und Zeitgeschichte.

Viel Spaß beim Schmökern

Gruß

Aga

Ich glaube, man muss ganz klar bei Access unterscheiden:

1. Programme IN Access geschrieben
2. Programme, die nur die Jet-Engine (d.h. MDB-Access-Dateien) verwenden

Zu (1) hat Agawain erheiternde (wenn es nicht so ernst wäre) Geschichten auf Lager, die ich nur bestätigen kann.
Zu (2) fällt mir außer "Einzelplatz hui, Mehrplatz (Netz) pfui" nicht viel ein, außer das es eben eine wirklich stabile und brauchbare Lösung ist.

Ich stehe zu einer Verwendung, wenn es denn eine kleine Desktop-Anwendung sein soll, Die Jet-Engine ist doch eh überall dabei und wirklich recht flott. Ok, embedded XX-SQL (XX=My, FireBird etc.) ist auch akzeptabel...

alzaimar hat folgendes geschrieben:

Ich glaube, man muss ganz klar bei Access unterscheiden: 1. Programme IN Access geschrieben Zu (1) hat Agawain erheiternde (wenn es nicht so ernst wäre) Geschichten auf Lager, die ich nur bestätigen kann.

also da gibts ja schon wieder Widerspruch

daß in einem Redmonder int, wenn int draufsteht, nicht unbedingt int drin steht, ist völlig unabhängig davon zu betrachten, was danach weiter mit den Daten geschieht...ich hab sie in einem Report verarbeitet...das wäre mir aber in Delphi genauso passiert...das einzige, was man sagen kann, wenn ich ne eigene Inportroutine geschrieben hätte und typgenau übergeben hätte und nicht die von Access genutzt hätte, wär das vielleicht nicht passiert...obwohl warum hätte ich das tun sollen, wenn int dransteht, muß man ja eigentlich davon ausgehen, daß die Nachkommastellen abgeschnitten werden. Jedenfalls liegt die Vermutung nahe, daß damals die Felder intern eher variant als alles andere waren.

Habs mal gerade getestet, liebe Access-User, Ihr dürft beruhigt sein...2003 macht son Dreck nicht mehr...

Trotzdem sind die Jungens immer wieder für kleine Späßchen gut.
Letzten Freitag erst...ok, das war jetzt Excel...aber tja...nennen wir das nun Bug oder Feature.
Wir geben an unsere Kunden Excel-Dateien, die diese mit ihren Absatzdaten füllen...damit es halbwegs übersichtlich bleibt, gibt es darin Gruppenüberschriften...um zu verifizieren, daß auch alle Artikel übernommen werden können, haben wir erstmal die Gruppenüberschriften entfernt, indem wir nach leerer Artikelnummer gefiltert haben und die entsprechenden Zeilen rausgeschmissen haben, warum das, ist noch nen anderes Procedere, ich war nämlich entsetzt, als ich es gesehen habe, spielt jetzt auch keine Rolle.

Jedenfalls die Scheußlichkeit, in Delphi geschrieben, die dann die Daten importiert, kommt wohl mit Leerfeldern klar. Dann Gegenprobe über den Filter gemacht...in der Filterbox standen nur die Artikelnummern und die Zahlen....ABER...aus welchen Gründen auch immer...mein Chef hat bei 3 Gruppenüberschriften nen Punkt in die Spalte Artikelnummer gemacht.
Und da hats dann beim Import geknallt, das verträgt die Scheußlichkeit nämlich nicht...für die ist das Feld nämlich nicht leer und kontert prompt mit Artikel-Nr nichtgefunden.

Wobei die Scheußlichkeit, deren Tabellenwerk ich heute mühselig wieder repariert habe, ausnahmsweise recht hat...was fällt den Redmondern denn ein...was ist denn ein Punkt für die, nicht Fisch nicht Fleisch?, deshalb...Fliegendreck, kann man ignorieren.

Ich weiß jedenfalls, auf was wir uns morgen freuen dürfen...knapp 200 Excel-Tabellen nacharbeiten...Yeah

Also diese etwas merkwürdig bevormundende Art von Redmond sorgt nicht nur für Irritation, sondern für üble Fehler.

Darum sag ich mal, ich oute mich, ich arbeite auch mit Access für Quick und Dirty, aber je mehr ich von dem Quatsch mitkrieg, desto mehr komm ich davon ab, Desktop, oder Netzwerk ist mir egal...die machen einfach komische Sachen.

Gruß

Aga

Agawain, ich muss sagen, Du solltest Dir mal genau überlegen, WAS Du da genau machst und sagst. In meinen Augen schiebst Du die Unzulänglichkeiten bei der Modellierung auf externe Anwendungen, und wenn die von Microsoft sind, dann ist deine Vorstellung eines Feindbildes 100%ig erfüllt.

Sei mir nicht böse, aber Dir fehlt, gelinde gesagt, die Objektivität, um zwischen Selbstgemachten und Bugs in fremden Anwendungen zu unterscheiden. Ich bin sicherlich kein Freund von Microsoft, Access, Excel oder Word, aber Deine Vorstellungen von der Arbeitsweise dieser Software decken sich einfach nicht mit den Zielsetzungen der Entwickler.

Umlaute sind wirklich ein Greuel in Feldnamen, aber SQL erlaubt nun mal Leerzeichen. Wenn Dir das nicht passt, dann ist das ja wohl nicht die Schuld von Microsoft, oder? Wenn Oracle keine Underscores akzeptiert, spricht das denn dann wirklich automatisch gegen Microsoft?

Du projezierst deine eigene Sicht der Dinge in fremde Software und wenn sie nicht erfüllt werden ist die Fremdsoftware Müll und nicht zu gebrauchen. Ein wenig mehr Flexibilität wäre sicherlich angebracht. In diesem Zusammenhang finde ich es auch bezeichnend für Dein Verhältnis zur Objektivität, das Du eine sehr bewährte und altersschwache Software mit 'Scheußlichkeit' titulierst. Das ist unsachlich, polemisch und bringt Nichts. Au0er Gelächter. Aber irgendwann ist das nicht mehr lustig.

Wenn Eure Import-Tools fehlerhaft oder ungenügend sind, dann schieb das doch nicht auf die externen Tools. Ich bekomme immer noch jede EXCEL-Tabelle importiert, einfach dadurch, indem ich Excel als das ansehe, was es ist und die richtigen Werkzeuge für die richtige Aufgabe verwende. Du kannst doch nicht den Hammer verteufeln, weil man damit keine Schrauben eindrehen kann.

Ich habe diverse Access-DB seit mehr als 6 Jahren 24/7 im Einsatz, ohne Abstürze, DB-Problemen, Indexfehlern o.ä. Ich importiere hunderte von Access-Tabellen und kann -bis auf die lustigen Datenfehler, die man mit Try-Except ignorieren kann- nicht über irgendwelche unpberwindbaren Probleme referieren. 50% der DB-Anwendungen in USA basieren auf Access. Auch wenn Access überbewertet wird (was sich Gott-Sei-Dank ändert), ist es doch ein verdammt gutes Tool, um DB-Awendungen für Jedermann zu ermöglichen.

EXCEL-Tabellen importiere ich mit externen Tools, ich exportiere mit den gleichen Tools und bin erstaunt, wie robust Excel damit klar kommt: Die externen Tools sind bedingt durch die unvollständige BIFF-Doku nicht 100% perfekt, aber einmal durch Excel gejagt ist die Welt wieder in Ordnung. Eine Sache ist aber wirklich krank, nämlich das BIFF-Dateiformat. Also DAS ist wirklich Rumgefrickele.

Wenn ich schreibe, das man getrost Desktop-Anwendungen in Delphi schreiben kann, die mit Access-Dateien unter Zuhilfename der Jet-Engine/ADO arbeitet, dann ist es kontrakproduktiv und irrelevant, wenn Du mit Anekdoten über Excel-Import daherkommst. Ich sehe ehrlich gesagt nicht, wo das meine Aussage irgendwie relativiert.

Also, lass mal die Kirche im Dorf.

Hallo

Mit ihre Scheußlichkeit meinte ich ein Programm, was hier seit ein paar Jahren läuft...es ist in Delphi geschrieben, ich darf mich nur ständig mit dem Drecksoutput beschäftigen und hab den Quelltext nicht.

Soweit geb ich Dir recht, daß mein von irgendwelchen Feld- Wald und Wiesenproggern erstelltes Horror-Kabinett hier wirklich nicht durch die Redmonder getoppt werden kann.

Übrigens läuft die Schäußlichkeit auf der Basis von Paradox, siehe auch anderen Thread Inkonsistenz.

Das Hauptübel liegt bei dieser Scheußlichkeit, daß das DB-Design schon mal unter aller Kanone ist...ich hab da 2 Tabellen...eine, die die Produkte eigentlich beschreibt und eine 2. die man durchaus auch noch zu den Stammdaten zählen kann, die permutiert dann aber Lieferanten und Artikel...das macht dann auf knapp 3000 wirklichen Artikel 1 Mio Datensätze in Tabelle 2 davon werden maximal 10% wirklich gebraucht und an die externe Artikel, nämliche unsere, komm ich nur über das Monster

Aber ich hab noch 2 andere Scheußlichkeiten hier, die sind in Access programmiert, auch da sag ich...eher ein Problem der Progger, als der DB, mich wundert nur, daß unser Arbeitsvorbereiter damals was Besseres hingekriegt haben als die..Doppelte Rechnungsnummern, überschriebene Rechnungen...alles kein Problem.

Mir fehlt die Objektivität keineswegs, allerdings, ich trau Access immer weniger und ich habe gesagt, wenn die Scheußlichkeit erkennt, daß ein Punkt ein Zeichen ist, dann ist das gut.

Das Excel das nicht erkannt hat, ist nicht gut, denn inkonsequenterweise gehört der Punkt auch nicht zu der Kategorie Leer. also irgendwie gehöhrt der Punkt zu nichts, weiß ich nicht, nichts ist auch falsch...und das ist der springende Punkt, bzw. das hüpfende Komma...der fliegt aus jedem Filter raus.
Über Filter Punkt wirst Du niemals filtern können.
Ich geb ja zu, daß das mal wieder ne schräge Sache ist, aber es ist so.

Meine kleine Oracle-Geschichte hatte überhaupt nix mit Redmond zu tun, sondern damit, daß man es nachwievor nicht machen sollte...bzw. nach Möglichkeit meiden...Unterstriche, Leerzeichen, Umlaute in Feldnamen etc....solche Dinge können immer noch gut knallen und wirklich Vorteile bringt es keine, also sollte man sowas meiden.

Und laß mal, meine Modellierung ist in Ordnung, ich hab hier 5 kleine Scheußlichkeiten, seit Mitte Januar sind es nur noch 3. (komm mir her vor, wie in der Karibik, lauter kleine Inseln, aber nicht genug Sonne
Überhaupt, was fällt Dir ein, meine Modellierung anzuzweifeln *G*

So und jetzt laß da mal das Kriegsbeil in eine tiefe Grube sacken.
Ich hab mich für einen Weg entschieden, der mich weiter wegbringt von Microsoft, aus dem einfachen Grund, das ist mir alles zu schräg...ich arbeite auch weiterhin mit Microsoftprodukten, aber wenn ich Alternativen habe, die nicht wesentlich aufwendiger sind, dann nehm ich die.

Ach übrigens Excel-Blattschutz kann man wohl locker mit OpenOffice aushebeln.

Gruß

Aga

Hi, Aga und Alzi,

ja, ihr seid die "Zoffer"!

Ok, soll ich denn nun auf MySql gehen? Es ist zwar eine Einzelplatzlösung, aber ich strebe eine Mehrplatzlösung an.

Viele Grüße, Detlef

Hi

Tja, die Wahl der Waffen

Es kommt doch drauf an, was Du willst.

Willst Du Dein Programm verkaufen?
was macht Dein Programm?
welche Kundschaft?

im privaten Bereich, oder nur firmenintern...mysql+corelab...ohne was verkaufen zu wollen...aber ca. 52 € zahlen für die CoreLab-Lizenz...bin glücklich damit, denn das trifft zur Zeit genau meine Arbeitssituation, waren ja auch nicht meine 52 € , obwohl ich die trotzdem ausgeben würde, um den ganzen ODBC-Ärger lozuwerden

MSSQL ist eine Option, dann von mir aus mit ADO, bleibt halt in der Familie..wenn man erstmal umstellen möchte......wie Bernhardt Geyer sagte, mssql gibts erstmal so...aber meine Meinung...Konsequenz teuer, wenn Du verkaufen willst, kommt auf die Klientel an.

Also, da gehöhrt ein wenig mehr Definition dazu, heißt sag, was Du vor hast, dann kann man Dir was sagen

Und nein, Alzaimar und ich sind nicht Zoffer...oder man wird sehen;)

Und MySQL, MSSQL, ORACLE, FIREbird, PostgresSQL....alles mehrplatzfähig,,,Access auch, zumindest 97, das weiß ich

Hi, Aga,

nun, verkaufen will ich das Programm schon, aber es soll sich in eine bestehende Schulverwaltung "einklinken", indem es nur die Stammdaten der Personen = Lehrkräfte, Schüler nutzt.

Ich sauge also einmal den Personenstamm, und muss dann zurzeit separat weiterarbeiten, weil sich mein Personenstamm von dem Schulstamm unterscheiden kann, aber das ist für die Zukunft (nach dem Umstellen) kein Problem, denn es muss ja nur sichergestellt sein, dass eine Person erst gelöscht werden kann, wenn sie keine Bücher der Schule mehr hat.

Ich muss wohl klären, welches DBS dort zur Verfügung steht, ich vermute aber ganz stark, dass es FOXPRO-basiert ist.

Viel Unterstützung bekomme ich da nicht, weil die bedienenden Personen - gelinde gesagt - keine Ahnung haben, und auch keine haben müssen, da sie ja "nur" bedienen.

Danke für deine (eure) guten und sehr ausführlichen Ideen bisher und bis auf weiteres,

Detlef

Hi Detlef,

Schulen haben nie Geld...also sollte es schon Firebird, PostgresSQl sein.
Da Du das Programm verkaufen willst, fällt MySQL leider flach, denn da kostet der Server dann so an die 500 $ im Jahr...für öffentliche Schulen in der Regel nicht tragbar.
MSSQL noch teurer, also dito.

Der von Dir erwähnte Interbase Server wäre eigentlich ne Option, allerdings eigentlich wurscht, denn Firebird ist ein Abkömmling von Interbase.

So, die beiden genannten DBMS stehen unter BSD-Lizens, das bedeutet, man darf sie auch weiterreichen, ohne seinen eigenen Quelltext preisgeben zu müssen, Du mußt nur die Copyright-Hinweise bei der Weitergabe beachten.

Das Einstiegsmodell wäre sicher Firebird, denn bei PostgresSQL handelt es sich um eine Objektrelationale Datenbank. Die kann sich wohl auch wie eine stinknormale DB verhalten, aber ich hab keine Ahnung, wie sich das Teil dabei anfühlt. Na ja im Urlaub mal gucken.

Ich würde an Deiner Stelle mal Beides ausprobieren.
Was mir an Deiner Stelle auch noch wichtig wäre, daß die Datenbank unter Linux und Windows lauffähig ist und Dein Programm ohne Änderung lauffähig ist.
Beide Datenbanken gibts für beide OS, wobei der Ursprung Firebirds logischerweise Windows ist und PostgresSQL aus der Linux-Welt stammt.

Um den FoxPro oder was auch immer Zugriff mußte Dir keine Gedanken machen, läuft alles im Mischbetrieb, wirst nur dann die BDE nicht ganz los, das ist aber für den von Dir beschriebenen Anwendungsfall auch nicht schlimm.

Zusammengefaßt, für den Schulbetrieb neige ich tendenziell zu Firebird, da der möglicherweise auch bei Info-Projekten eher eingesetzt wird, als PostgresSQL.

Gruß

Aga

Agawain hat folgendes geschrieben:

[...] Schulen haben nie Geld...also sollte es schon Firebird, PostgresSQl sein. Da Du das Programm verkaufen willst, fällt MySQL leider flach, denn da kostet der Server dann so an die 500 $ im Jahr...für öffentliche Schulen in der Regel nicht tragbar. MSSQL noch teurer, also dito. [...]

Nur der Vollständigkeit halber sei noch erwähnt, dass es sowohl von Microsoft als auch von Oracle zu den "ausgewachsenen" Datenbanksystemen aus selbigen Häusern binärkompatible kostenfreie Versionen gibt, namentlich MS SQL Server Express und Oracle XE.

Hi, Aga und Robert,

nochmals vielen Dank für eure ausführlichen Antworten.

Dann werde ich wohl auf Firebird gehen! Ist hier im Forum ja auch schon häufig empfohlen worden.

Wer hat noch eine "Anleitung" wie man eine Firebird-DB anlegt?
Oder ist das automatisch Interbase mit Firebird-Server?

Bis (hoffentlich) bald,
Detlef