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 )


Tu Dir und dem Anwender einen Gefallen:

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 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.
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.