Mehrnutzerumgebung realisieren

[Ben Graf]

Ich frag mich grad hat kein Vb.Net programmierer interesse an Multiuser Anwendungen

Egal ob Bücher oder Foren, nie mal ein anständiges Beispiel was zu machen ist wenn mal 10 User gleichzeitig Daten in die Datenbank prügeln.

Probleme die man mit DAO damals überhaupt nicht hatte mit vb.net und ado.net zu lösen sind für mich immernoch schier unmöglich

gibts da irgendwo Infomaterial oder mal sinnvolle Beispiele auch mit SQL- Server (express) und nicht immer mit einer Access MDB

Ich hab hier mal bissel rumprobiert und bekomme beim ändern von einem Datensatz an 2 Clients beim Update des Dataadapter diese Fehlermeldung

"Parallelitätsverletzung: Der UpdateCommand hat sich auf0 der erwarteten 1 Datensätze ausgewirkt"

reagiere ich jetzt mit einem Try catch und sage dem Anwender "Stop da hat sich was geändert, die aktuellen Daten werden neugeladen!"
Ein neues Fill machen und die aktuellen Daten werden aktualisiert?

geht man so vor, oder sieht vb/ado .net einen aderen, besseren lösungsweg vor.

Mich interessiert erstmal grundsätzliches in der Welt der Mehrnutzerumgebungen aber ich finde leider nicht viel Infos darüber.

Was macht man bei einer Anwendung wo 15 Arbeitsplätze im Sekundentakt Bestellungen anlegen mit der fortlaufenden Belegnummer fürs Finanzamt
fragen über fragen

[Ralf Jansen]

reagiere ich jetzt mit einem Try catch und sage dem Anwender "Stop da hat sich was geändert, die aktuellen Daten werden neugeladen!"
Ein neues Fill machen und die aktuellen Daten werden aktualisiert?

geht man so vor, oder sieht vb/ado .net einen aderen, besseren lösungsweg vor.

Zum Beispiel. Es liegt in deiner Hand welche Regelung in deiner Anwendung Sinn macht. ADO.Net macht dir da eigentlich keine großen Vorgaben wie das zu machen ist oder was ~richtig~ ist.

Mich interessiert erstmal grundsätzliches in der Welt der Mehrnutzerumgebungen aber ich finde leider nicht viel Infos darüber.

Es gibt nicht die Mehrnutzerumgebung. Das ist wie immer Anforderungsgetrieben und je nach Anforderung fällt dann die Umgebung anders aus.

Was macht man bei einer Anwendung wo 15 Arbeitsplätze im Sekundentakt Bestellungen anlegen mit der fortlaufenden Belegnummer fürs Finanzamt

Wenn du multiple Batchjobs hast die in sich zwingend fortlaufende Belegnummern brauchen sehe ich 2 Möglichkeiten.

A.) Benötigten Nummernkreis in einer eigenen Transaktion vorher ranholen. Mit dem Risiko wenn der Job nicht durchläuft das diese Nummern weg sind. (Sollte eigentlich kein Problem sein fürs Finanzamt)

B.) Batchjobs serialisieren. Also immer schön einen ganzen Batchjob nach dem anderen. Könnte dazu führen das einzelne Jobs länger dauern bis sie ausgeführt werden deine Numemrn sind aber fortlaufend und lückenlos.

[Ben Graf]

Jetzt hast du mich noch mehr verwirrt

Es liegt in deiner Hand welche Regelung in deiner Anwendung Sinn macht. ADO.Net macht dir da eigentlich keine großen Vorgaben wie das zu machen ist oder was ~richtig~ ist.

in welche Richtung muss ich denn suchen um Infos über die Möglichkeiten zu bekommen

Es gibt nicht die Mehrnutzerumgebung. Das ist wie immer Anforderungsgetrieben und je nach Anforderung fällt dann die Umgebung anders aus.

Ohje das klingt nach viel prgrammierarbeit

Wenn du multiple Batchjobs hast die in sich zwingend fortlaufende Belegnummern brauchen sehe ich 2 Möglichkeiten.

A.) Benötigten Nummernkreis in einer eigenen Transaktion vorher ranholen. Mit dem Risiko wenn der Job nicht durchläuft das diese Nummern weg sind. (Sollte eigentlich kein Problem sein fürs Finanzamt)

ok gehen wir von der erste Möglichkeit aus falls eine transaktion nicht durchläuft kann ich sie ja beim nächsten mal benutzen ich glaube Tages intern sollte die vortlaufende Nummer jetzt nicht noch an der Uhrzeit herangezogen werden

Du meinst aber damit "einfach ausgedrück" ich suche mir beim speichern des Satzes die letzte Belegnummer und schnapp mir die für den neuen Beleg. Oder?

[Ralf Jansen]

in welche Richtung muss ich denn suchen um Infos über die Möglichkeiten zu bekommen

Keine Ahnung. Ich kenne deine Anforderungen nicht. Stichworte wären vielleicht Optimistic Locking, Pessimistic Locking, Reconcilation etc. Könnte jetzt aber von mir zu weit gedacht sein. Vielleicht nennst du uns einfach deine Anforderung wie es funktionieren soll dann kann man dich in die passende Richtung lenken.

Du meinst aber damit "einfach ausgedrück" ich suche mir beim speichern des Satzes die letzte Belegnummer und schnapp mir die für den neuen Beleg. Oder?

Wenn du dich auf meine a Variante beziehst nein. Einfach sich die letzte Belegnummer schnappen geht nicht. Was machst du wenn 3 Belege gleichzeitig erstellt werden? Die letzte Belegnummer wäre für alle 3 Beleg noch die gleiche. Zumindest das ziehen der nächsten Belegnummer musst du synchronisieren. Viele Datenbanken haben für solche Zwecke Generatoren die eindeutige Nummern auswerfen. Bei Microsoft Datenbanken müsstest du entsprechendes nachstellen (z.b. mit AutoInc Spalten).

[Ben Graf]

Wenn du dich auf meine a Variante beziehst nein. Einfach sich die letzte Belegnummer schnappen geht nicht. Was machst du wenn 3 Belege gleichzeitig erstellt werden? Die letzte Belegnummer wäre für alle 3 Beleg noch die gleiche. Zumindest das ziehen der nächsten Belegnummer musst du synchronisieren. Viele Datenbanken haben für solche Zwecke Generatoren die eindeutige Nummern auswerfen. Bei Microsoft Datenbanken müsstest du entsprechendes nachstellen (z.b. mit AutoInc Spalten).

Ja klar versteh ich, allerdings ist eine AutoInc Spalte schlecht an dieser Stelle da viele Ihre Nummernkreise oft ändern. Vorschrift sind glaube ich nur fortlaufende Belegnummern.
Wenn man mit 50001 im Januar anfängt und im Juni braucht man jetzt Belege ab 70001 soll da weiter gezählt werden. Für den Notfall muss die Belegnummer allerdings bei uns auch noch von Hand änderbar sein. Vorher haben wir es so geregelt:
Wir haben eine Tabelle-Einstellungen dort wird immer die nächste Belegnummer abgelegt. Bei einem neuen Beleg wird diese Tabelle gesperrt solange bis der neue Beleg sich die Nummer geschnappt hat und um eins hochgezählt hat.
Auch nicht gerade das gelbe vom Ei, aber bis jetzt hat es gereicht...

Vielleicht nennst du uns einfach deine Anforderung wie es funktionieren soll dann kann man dich in die passende Richtung lenken.

ok ich gehe dann mal von den beiden extremen aus Kunden und ihre Belege
Szenario Firma X mit 15 Arbeitsplätzen im verkauf. 1 Arbeitsplatz kümmert sich um Onlinebestellungen(dieser Weg muss jetzt nicht beschrieben werden wie es geht nur was passiert)

Ein ganz normaler Arbeitstag :

Bei 15 Mitarbeitern klingelt das Telefon im Minuten Takt
Bestellungen werden gleichzeitig erfasst,
Auftragsbestätigungen werden erstellt, Lieferschein ins Lager, Rechnung an den Kunden
Zwischen durch mal noch ne Gutschrift oder was weiß ich alles
jeder Belegtyp hat einen eigenen Nummernkreis

Ab und zu kommt auch mal ein Neukunde dazu, kommt aber eher selten vor das sich die 15 Mitarbeiter da in die quere kommen. Aber es wäre möglich.

Soweit zu deren Arbeitsablauf.

jetzt kommt die Kiste ins spiel mit Online-Bestellungen.
Bestellung kommt rein
Es wird geschaut ob alles auf Lager ist
Die Auftragsbestätigung wird verschickt
Lieferschein ins Lager
Rechnung zum Kunden

also soweit das gleiche was die anderen Mitarbeiter machen. Allerdings
in einem Höllen Tempo. An guten Tagen habe wir mit der alten Software im 5- 10 Sekunden Takt Bestellungen.

Fazit Access Pakts .Net, wird langsam etc...
Lieber Programmierer mach alles neu mit SQLServer und VB.net ;-)

[Ralf Jansen]

Bei einem neuen Beleg wird diese Tabelle gesperrt solange bis der neue Beleg sich die Nummer geschnappt hat und um eins hochgezählt hat.
Auch nicht gerade das gelbe vom Ei, aber bis jetzt hat es gereicht...

Das sollte bei eurem Transaktionsaufkommen eigentlich kein Problem darstellen auch wenn damit die Belegerstellung komplett serialisiert ist. Wenn doch kann man das wie gesagt in eine eigene Transaktion auslagern. Dann ist die Nummer halt weg wenn die nachfolgende Belegerstellung nicht durchgeht.

Fazit Access Pakts .Net, wird langsam etc..

Nach deiner Beschreibung kann ich leider nicht einsehen warum das langsam sein sollte. Schon das Standardverhalten von ADO.Net ohne manuelle Anpassung der SQL Statements sollte dafür eigentlich mehr als ausreichen. Wo das Performanceproblem liegen könnte ist auch schwer vorhersagbar. Wenn du keinen Ansatzpunkt hast würde ich mit dem SQL Profiler auf die Datenbank schauen was für SQL von der Anwendung an die Datenbank gehen. Und dann gezielt diese SQLs anpassen bzw. aus den gewonnen Erkenntnissen die Anwendungslogik überdenken.

[Ben Graf]

ich hab jetzt nur mal die Anforderungen erklärt, bzw den VB6 Stand mit einer alten Access Datenbank darunter
Deine Antwort verwirrt mich jetzt etwas

ich dachte du wolltest mir nen Ansatz geben in Multiuser Problemen

und der letzte Satz war nur darauf bezogen das access bei ein paar Kunden an die grenzen des machbaren stößt da unsere Kunden sehr verwöhnt sind
so auf die Art:
ne volltext Suchanfrage in der Artikel Tabelle mit 75000 Datensätzen darf halt keine 2 Sekunden dauern ....