Access DB multiuser fähig

[Salomon]

Hallo,
die Überschrift sagt eigentlich schon alles. Mein Programm greift mittels ADO auf eine Access DB zu. Später soll die DB und das Programm auf einem Netzlaufwerk abgelegt werde, wo es mehrere User gleichzeitig benutzen sollen.

Ist dies soweit mit einer Access DB möglich, oder muss ich da auf eine andere DB umsteigen?

Auf den Clients soll keine Software installiert werden.

Thanx
marcus

[Jelly]

Du schreibst, "später" soll die DB auf ein Netzlaufwerk gelegt werden. Daraus ziehe ich, dass es eine neue Anwendung ist, an der Du dich da grad versuchst. Daher mein Tipp: wenn es nicht unbedingt vorgeschrieben ist, eine Access DB zu sein, dann nimm lieber gleich ein richtiges Datenbanksystem. Als Upgrade zu Access bietet sich da förmlich der SQL Server 2005 an, in der Express Version kostenlos.

[Phoenix]

Access ist eher leidlich Multiuserfähig. Bis 5 User die nicht immer gleichzeitig auf den gleichen Daten rotieren ist das okay, bei größeren Benutzerzahlen / vielen konkurrierenden Zugriffen streckt das Datenbankfile öfter mal alle Viere von sich und muss aufwendig repariert werden (sofern noch möglich).

[Salomon]

@ Jelly: Richtig, die Anwendung entwickel ich momentan. Access wird verwendet, weil vorher geplant war das ganze rein in Access zu realisieren. Doch Delphi bietet für die Oberfläche wesentlich mehr Funktionen... Das mit dem SQL Server wäre eine Überlegung wert. Allerdings müsste dann immer ein Server die DB hosten.

@Phoenix: User sind es ca. 50. Wieviele da jetzt gleichzeitig drauf zugreifen ist schwer abzuschätzen. Aber so 5 werden es schon sein...

Noch 2 Fragen:

Ist es möglich durch Angabe eines anderen Connection Strings bei den ADO Komponenten ohne Änderungen am Programm auf eine andere DB zuzugreifen? So eine gewisse DB unabhängigkeit im Programm? Die Abfragen sollten sich alle mit standard SQL Befehlen realisieren lassen.

Gibt es noch andere DBs, bei denen ich keinen DB server installieren muss? Ich benutze die Turbo Delphi 2006 kann also keine neuen Komponenten installieren.

[hoika]

Hallo,

zu 1.:
Nein, SQL heisst nicht (S)tandard, sondern (S)trukturierte Query Language.
Selbst Access / ms-sql ist stellenweise sehr verschieden (Feldtypen).

zu 2.:
Was spricht gegen einen Server.
zur Not kann auch einer der Nutzer-Rechner den Server mitlaufen lassen,
empfohlen ist es nicht.


Es gibt übrigens "Access-Project" (Löhnware),
damit kann man unter Access direkt auf mssql zugreifen,
ich meine nicht nur den Zugriff,
sondern auch alle Assistenten.

Wie schon gesagt, dem Vorteil von Access (frei verfügbar, kost nix),
stehen ne Menge Nachteile gegenüber.
Ab 20 gleichzeitigen Nutzern ist es übrigens je nachdem,
was man macht, gar nicht mehr zu bedienen (saulahm)


Heiko
PS: Das habe so alles mal von Access-Nutzern gehört.

[Jelly]

Wenn du Access nutzt, brauchst du auch permanent einen Rechner laufen, der die Datenbank hostet. Wo ist der Unterschied.

Bei 50 Usern würd ich definitiv die Finger weg lassen von Access. Da wirds früher oder später gewaltig knallen. Access ist einfach nicht dafür ausgelegt.

Wenn Du die ADO Komponenten nutzt, kannst du recht problemlos den Connectionstring anpassen und eine andere Datenbank zugrunde legen. Aber bedenke, jede Datenbank verhält sich in gewissen Punkten etwas eigen, auch wenn Du dich an Standard SQL hälst. So mach MSSQL z.B: keine Unterscheidung zwischen Klein- und Grossschreibung, MySQL schon.

[alzaimar]

Wenn Du eine Anwendung für 50+ Benutzer schreibst, dann verdienst Du vielleicht doch Geld damit. Investiere in die Professional Version von Delphi und kauf Dir ein paar ordentliche Controls (Grids, Reporting Tools etc.). Das Geld hast Du locker wieder raus. Verdienst Du *kein* Geld damit, dann lass es.

Ein großes Logistikunternehmen in Deutschland, einer unserer Kunden, hat jahrelang eine Faktura-Lösung auf Access-Basis verwendet. Der technische Leiter war 1-2x im Monat damit beschäftigt, die DB wieder zu reparieren: Die in der Zwischenzeit im Sekundentakt (Callcenter) eintrudelnden Requests und Aufträge mussten dann aufgeschrieben und anschließend, wenn die DB wieder repariert war, manuell eingepflegt werden.

Die Datensätze und Rechnungsdaten, die durch den Crash flöten gegangen sind, summierten sich auf ca. 1-3% des Jahresumsatzes.

Mittlerweile sind sie -dank uns- auf MSSQL umgestiegen: Der technische Leiter kann endlich seiner Arbeit nachgehen, weil es eben *nicht* mehr vorkommt, das irgend etwas crashed (außer unserer Software, aber das ist ein anderes Thema :stupid: )


Tu Dir und dem Anwender einen Gefallen:

Zitat:

Zitat von Das Leben

Lass die Finger von Access, wenn mehr als 5 Leute damit arbeiten

Installiere einen separaten DB-Server mit guter Hardware, 1GB RAM und einem ordendlichen Prozessor (i.a. muss der nicht sooo schnell sein). Investiere in gute Festplattenhardware, wenn's geht nimm ein RAID-System.

Such Dir eines der freien DBMS aus (Firebird, MSSQL Express, PostgreSQL...) Vermeide MySQL, denn dass ist NICHT UMSONST!

Viel Spass (Denn Spass wirst Du mit den o.g. DBMS haben, mit Access eher Suizidgedanken und Rachegelüste der Anwender)

[Salomon]

Danke für die vielen Infos! :)

Das Programm wird was ähnliches wie ein Ticketsystem für Projektaufgaben und wird später in der Firma eingesetzt wo ich tätig bin. Evtl. kann ich die Projektverantwortlichen dazu bewegen einen "richtigen" DB Server einzusetzen und entsprechende Delphi DB Komponenten zu kaufen. Vorerst werde ich jedoch wohl mit den ADO Komponenten auskommen müssen.

Stabil muss das ganze schon laufen. Danke für den Hinweis das mySQL nicht kostenlos ist. Aufgrund von Webhostern & XAMPP erliegt man leicht diser Vermutung.

[alzaimar]

ADO ist schon ok, zur Not tun's auch die normalen DB-Controls.

Aber unbedingt ein richtiges DBMS. Die Verantwortlichen gehören geteert und gefedert und danach in die Klapsmühle, wenn sie auf Access bestehen.

[Elvis]

Zitat:

Zitat von alzaimar

Aber unbedingt ein richtiges DBMS. Die Verantwortlichen gehören geteert und gefedert und danach in die Klapsmühle, wenn sie auf Access bestehen.

Amen. :angle2:
Du vergisst aber noch die, die heutzutage noch solche "passt schon"-Scheiße wie Apps auf Access/Jet-Basis zusammenfriemeln.

Ich will gar nicht wissen wie viele User von ElsterFormular ihre Daten dank dieses Krüppelviechs verloren haben, oder einfach nur Zickereien mit dem Programm bekamen.

[delphirocks]

FULL ACK!

Wir verwenden Access 97 als Single User DB, allerdings greifen mehrere Prozesse gleichzeitig darauf zu.
Alles was ich dazu sagen kann: Finger weg, alles was du dir anfangs an Entwicklungsaufwand ersparst, bezahlst du später hundertfach zurück.

Es gibt so viele bessere Optionen gratis: SQLServer Express, Firebird, Postgres, Oracle Express (bis 4 Gig), DB2Express, teilw. MySql.

Also Finger weg von Access!

[Reinhard Kern]

Hallo,

es ist überflüssig irgendwelche Listen und Rangfolgen bei DBs anzulegen, jedenfalls für die vorliegende Frage, denn Access würde immer mit Abstand den letzten Platz belegen. Bei mehrfachen Zugriffen ist mit 1 Tag Komplettausfall für Reparaturen / Woche zu rechnen. Bei uns war Access besonders raffiniert und versetzte die DB meistens in einen nicht mehr reparierbaren Zustand, aber so, dass man es erst nach erneutem (nicht mehr möglichem) Einloggen bemerkte - also am nächsten Morgen.

Selbst uralte DBs wie DBase waren/sind weitaus stabiler zu betreiben, deshalb führt ja MS auch immer noch Fox mit, für kleinere, aber professionelle Anwendungen. Access ist eine rein PERSÖNLICHE DB, für 1 Nutzer, dem seine Daten nicht so wichtig sind.

Gruss Reinhard

[Jelly]

Zitat:

Zitat von Reinhard Kern

Access ist eine rein PERSÖNLICHE DB, für 1 Nutzer, dem seine Daten nicht so wichtig sind.

Netter hätt ich's auch nicht formulieren können. :mrgreen:

[Salomon]

Beim DBMS sind sich hier ja alle einig :thumb:

Es ist zwar noch nicht geklärt welcher Server nun später die DB hostet, aber es wird jetzt wohl ein MS SQL Server Express :-D

Ich bin gerade dabei mir die MS DB lokal zu installieren. Die vorhandene Access DB hat nur ein paar Tabellen mit einigen Testdaten. Lohnt es sich die "irgendwie" nach SQLServer Express zu importieren, oder sollte ich die lieber neu anlegen?

Wie legt ihr das Datenbankmodell an? Ich hab da noch nicht so viel Erfahrung. Bei PHP/MySQL habe ich dies meist im PHP Script oder mit PHPMyAdmin gemacht.
Sollte bei Delphi das neue Programm die Datenstruktur anlegen? (SQL ->Create table etc.) Oder besser mit fertigen Tools zum verwalten der DB?

Gruß
Marcus

[Phoenix]

Jenachdem, was zur Verfügung steht.

Ich bin inzwischen ein großer Fan vom CaseStudio2 (hat Quest Software gekauft, keine Ahnung wie das jetzt heisst). Das generiert Dir aus dem graphischen Modell automatisch ein komplettes SQL-Script raus. Einspielen -> Db fertig. Inkl. Initialer Stammdaten etc, sofern im Modell gepflegt.

Mit Visio sollte sowas angeblich auch gehen. Zumindest mal Modell in die DB packen.

Access als Frontend um Datenbanken im SQL Server zu designen ist auch okay.


Zum Einspielen: Kommt drauf an. Bei einer 'Ready to Go'-Lösung würde ich das Datenbankscript als Resource im Programm mitliefern. Connect -> Gucken ob Tabellen da sind -> Wenn nicht: Resource in die DB pumpen & loslegen.

Der Aufwand lohnt sich aber nicht, wenn die Anwendung eh nur selber installiert wird. Da ist man mit einem Script bewaffnet sicher etwas flotter und flexibler. Direkt via Tool ist ungeschickt, weil man das dann ja zum Kunden mitnehmen müsste, und nicht überall darf das eigene Notebook ins Netz oder sich gar als Admin an der DB anmelden.

[mkinzler]

http://www.fabforce.net/dbdesigner4/

[Phoenix]

Zitat:

Zitat von mkinzler

http://www.fabforce.net/dbdesigner4/

Um ganz ehrlich zu sein: Ich bin mit dem Ding inzwischen AAAARG unzufrieden.
1.) Der taugt nur wirklich für MySQL
2.) Für MySQL 5 taugt der schon nicht mehr (permanente Exceptions bei Verbindungsversuchen etc.)

Das Nachfolgeprojekt ist direkt vom MySQL-Projekt übernommen worden, hat aber noch massigst Bugs (u.a. viel zu kleine Schriftdarstellung, so dass man damit nicht richtig arbeiten kann).

Damals für MySQL 3, Anfänge von 4 war das ein Superprodukt, inzwischen aber kaum noch Praxistauglich. Leider :(

[mkinzler]

Es liegt aber im Sourcecode (Delphi) vor.

[Salomon]

Das Case Studio 2 heißt jetzt "Toad Data Modeler". Sieht ganz gut aus. Ich werde mal die Demo ausprobieren.
Zu finden ist das Tool hier.

Den DBDesigner habe ich trotz der Kritik mal zum testen heruntergeladen...

Letztendlich wird für meinen Zweck wohl die Erstellung eines Scriptes reichen, da die Datenbank nur einmal auf dem DB Server angelegt werden muss.

[Jelly]

Zitat:

Zitat von Salomon

Letztendlich wird für meinen Zweck wohl die Erstellung eines Scriptes reichen, da die Datenbank nur einmal auf dem DB Server angelegt werden muss.

Dann denk ich brauchst du noch nicht einmal ein Skript, sondern pflegst die Update einfach händig bei Bedarf.

Bei SQL Server 2005 Express (Vorsicht, nur bei der Express Version), können die Datenbank files (.mdf und .ldf) einfach kopiert werden. Dazu brauchts noch nicht einmal ein Backup/Restore.

[alzaimar]

Bei der 2005 Express Version ist doch der Enterprise Manager dabei, oder nicht? Dann kann man nämlich Daten einfach importieren. Gut, etwas Handarbeit ist dann noch notwendig, um z.B. Feldtypen zu korrigieren, aber soweit funktioniert das ganz gut.

[Jelly]

Den Enterprise Manager gibts nicht mehr beim SQL Server 2005. Genauso wenig den SQL Query Analyzer. Beides wurde ersetzt durch ein Tool namens SQL Server Management Studio bzw. SQL Server Management Studio Express. Das aber nur am Rande.

[Salomon]

Danke für den Tipp mit dem MS SQL Server Management Studio Express. Ich hab nach der Installation des Servers vergeblich nach Tools wie dem Query Analyser gesucht.
Das Tool kann hier geladen werden: DL