Hi!
Ich würde dich bitten die Bilder hier in deinen Post einzubinden. Externe Quellen sind nicht so vorteilhaft weil man erstmal nicht weiß was das für eine Adresse ist.
Zu deiner Frage... Ich vermute mal bei access ist irgendwas schief gegangen... Glaube nicht das es nach 3000 Datensätzen schon langsam wird... Hast du eine Eingabemaske und abfragen erstellt sowie die korrekten Datentypen verwendet?
Aber vielleicht können andere noch bessere Tipps als ich geben...

Schau mal hier rein: die vier Views auf Video

Willkommen im Forum.

KlausRene-Heize schrieb:

Hallo liebe c-plusplus Gemeinde

Falsches Forum? Doppelpost? Na egal.
Den Code kapier ich auch nicht. VB.Net, aber alles nur Prozedurrümpfe. Warum wurde das gepostet?
Das mit Access und > 3000 kommt auch mir spanisch vor. Auch wenn ich mit Access nix am Hut hab, sollte das für ein Mikrosaft-Programm kein Problem darstellen.
Die Frage, die sich mir stellt: Welche Datenbank ist in Benutzung? Oder gehst Du erstmal den (empfehlenswerteren) Weg namens DataSet-only?

Hi... Sorry wenn ich das so sage.. Aber das wird so nix... Weder in vb noch in c++ noch in sql... Ich würde dir empfehlen dich von vorne mit dem Thema zu beschäftigen.

Fang mit den Datentypen an und schau wie man sie verwendet.
Dann setzt euch zusammen und überlegt wer was eingeben soll
Dann schau dir die oben gezeigten Videos an um zu lernen wie man mit Daten umgeht. Und natürlich fehlt dann noch die Programmiersprache. C#, VB, Python, oder das erwähnte c++...

Es handelt sich zur reinen Datenerfassung. Es kommt ein Anruf und die ausgewählten Optionsfelder und Rufnummer sollen in einer Datenbank gespeichert werden. Mehrere User sollen damit gleichzeitig arbeiten. Dazu soll es drei Forms geben. 1für die Ziele, 2 zur Eingabe und später die Auswertung. Jetzt ist die Frage, wie bekomme ich die Zeile 1 in der Datenbank wenn ich Speichen drücke?

Aha, darunter kann ich mir aber sowas von gar nix vorstellen

Vielleicht willst du uns mit
A: Screenhots
B: einer belastbaren Aufgabenbeschreibung
erfreuen? Weil so kann ich mir da nix drunter vorstellen.

Meine Vorgehensweise wäre:
1. Datenmodell erstellen
2. Oberfläche erstellen
3. Vergessene Informationen im Datenmodell nachtragen (hihi)
4. Programmieren

@VaporiZed Multiuser Zugriffe im Typ. Dataset, geht das denn?

@mrMo: Nicht, dass ich wüsste. Mir ging es erstmal um einen vernünftigen Unterbau, bevor man die Datenbanken anschließt. Ich glaube, das wäre erstmal sinnvoll, da dieses Problem offensichtlich schon seit längerem besteht:
gleiches Thema bei auto-it
gleiches Thema im MS Office Forum
gleiches Thema im c-plusplus-Forum

Da ich unter einem tDS kein DBMS verstehe, dürfte das nativ nicht möglich sein. Aber vielleicht wissen @ErfinderDesRades und @VB1963 mehr dazu.

Das Grundlegende Problem eines tDS ohne Datenbank im Hintergrund ist letztenendes ein Synchronisierungsproblem in einer Multi-User Umgebung:
Nehmen wir mal Alice und Bob.
Alice und Bob starten entweder gleichzeitig oder kurz nacheinander das Programm auf ihren Rechnern (ausgehend davon, dass das Programm auf nem Netzlaufwerk liegt).
Nun laden beide die tDS aus der neben dem Programm liegenden XML. Kein Problem, denn das sollte ein reiner Lesezugriff sein.
Beide arbeiten in ihren Programminstanzen munter weiter und nach guten 15 Minuten ist Alice fertig mit ihrer Arbeit, und schließt das Programm, woraufhin das tDS in die XMl gespeichert wird.
Bob hingegen arbeitet noch 15 Minuten weiter und schließt erst dann das Programm wodurch wieder das tDS in die XMl gespeichert wird.
Jetzt haben wir aber ein Problem, denn Bob überschreibt damit die Daten von Alice. Wenn sie nun also das nächste mal das Programm aufmacht, sieht sie zwar Bobs Arbeit, doch ihre ist verschwunden.

Kurz gesagt:
Mit dem was das Framework an Methoden für DataSets anbietet, ist eine Multi-User Umgebung selbst auf einem Netzlaufwerk unmöglich.
Um sowas zu erreichen müssen extra Methoden geschrieben werden, die nur winzige Dateizugriffe Verursachen, sodass jeder seine Änderungen direkt in das XML überträgt, und nicht erst nach vollendeter Arbeit.
Dennoch bleibt das Problem der Synchronisierung. Wie bekommen andere meine Arbeit mit? Sollen die Ständig die XML Datei Parsen und nach Änderungen ausschauhalten? Etwas Übertrieben.

Der einfachste Lösungsweg wäre wohl oder übel eine Datenbank hinter dem DataSet, welches jedoch regelmäßig geupdated werden muss.
Und man muss sich noch überlegen, wie man gleichzeitige Updates auf einen Datensatz usw. handhabt. Man verschiebt das Synchronisiserungsproblem nur etwas.

Da muss in Access irgendwo ein grobes Problem sein! Wegen 3000 DAtensätzen mit ein paar Telefonnumern und Optionen passiert da gar nix. Ich hatte schon Access-Db mit einigen 100000 Datensätzen und allem Drum und Dran im Multiuser-Einsatz. Ist zwar dann keine Lichtgeschwindigkeit mehr aber immer noch akzeptabel.

@Klaus-ReneHeinze: Kannst Du evtl. mal deine Access-Db hier reinstellen? Es ist m.E. der bessere Weg wenn du (mit unserer Hilfe) die Access-Variante auf den richtigen Weg bringst als unter .NET (o.ä.) mit Dataset und Multiuser von quasi NULL anzufangen - da wirst du lange brauchen um wieder mal glücklich zu werden

mrMo schrieb:

Multiuser Zugriffe im Typ. Dataset, geht das denn?

Meinst du jetzt die App selbst, die intern mit einem typ. DS arbeitet oder die DB, wohin die Daten persistiert werden?
Also, der Weg über .XML (Dataset-Only) ist absolut nicht MultiUser-tauglich...

Die Sache ist eigentlich nicht wahnsinnig kompliziert. Nur wirst du hier von diversen Antworten und Lösungsansätzen bombadiert, so das du dich auf keinen Lösungsweg konzentrieren kannst.

Es gibt aber Licht am Horizont. Ich kann dir die ultimative Lösung, die auch langfristig gut funktioniert und unerwarteten Probleme gleich mit behebt, nennen. Oder kennste die vieleicht sogar schon selbst?

Ultimative Lösung

mrMo schrieb:

eine "richtige" Programmiersprache

Ist deiner Meinung nach welche?
VB.Net ist doch schon ziemlich "richtig".

petaod schrieb:

Ist deiner Meinung nach welche?
VB.Net ist doch schon ziemlich "richtig".

Der TE sprach Anfangs von einem Excel VBA Tool. Das "richtig" bezog sich auf alles was nicht VBA ist. VB.Net, C# und dergleichen würde ich demnach als "richtige" Programmiersprache bezeichnen.

VaporiZed schrieb:

... Ich glaube, das wäre erstmal sinnvoll, da dieses Problem offensichtlich schon seit längerem besteht:
gleiches Thema bei auto-it
gleiches Thema im MS Office Forum
gleiches Thema im c-plusplus-Forum
...

Wenn man sich diese Links mal durchliest sieht man schnell, dass der TE das Programm nicht selbst geschrieben hat, bzw. nur sehr geringe Teile. Es herrscht anscheinend weder der Wille noch das Vermögen irgendetwas für dieses Programm zu tun. Man möchte fertig gebratene Tauben haben.

mrMo schrieb:

Der TE sprach Anfangs von einem Excel VBA Tool.

​Das ist so nicht richtig, im ersten Post steht dass die erste Version in Excel VBA war.

@KlausRene-Heize
​Sie kommen ja anscheinend mit dem Projekt seit 3 Jahren nicht zum Ziel. Engagieren Sie einen Programmierer oder eine Firma, nehmen Sie ein paar tausend Euro in die Hand und Sie bekommen was Sie wollen. Schreiben Sie dazu ein Lastenheft in dem detailliert​ steht was Sie von dem Programm erwarten, geben Sie keinen Lösungsweg vor.

Was im ersten Post präsentiert wird ist quasi "Ich hab hier mal eine Skizze gemalt, wie das Programm aussehen soll. Das ist also fast fertig. Gebt mir mal fix allen Code dafür." Diese Einstellung sehe ich ständig in meiner Firma, das ist also nicht ungewöhnlich, es wurde jedoch bisher nur 5-10% des eigentlichen Weges beschritten. Es gibt hier dafür auch ein Unterforum "Marktplatz" wo man um Angebote für solch ein Programm bitten kann, vielleicht kommt man da billiger weg.

​Das ganze Topic ist übrigens gegen die Forenregeln, insofern ich sie richtig verstanden habe. Der Titel ist nichtssagend und schlecht gewählt, es wurde kein Beispielcode mit konkretem Problem gepostet. Es gibt keine konkrete Fragestellung.
Der Programmname ist weiterhin auch äußerst fragwürdig und in dem einem Bild (was wegeditiert wurde, ebenso wie irgendwelche "Beispielprogramme") wirkt das ganze wie eine Software für ein Callcenter wo rudimentäre Ziele erreicht werden müssen und Anweisungen stehen. Auch das wirkt wie dubiose Geschäftspraktik, von der ich persönlich die Finger lassen würde.

@KBT