Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Tabellen im Hauptspeicher bearbeiten statt in DB auf Platte
Gehe zu Seite 1, 2  Weiter
zurück: TimedMsgBox weiter: Vormonat auf Lable schreiben Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Feedback Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
JMalberg
Es wird so langsam sinnig ...


Verfasst am:
29. Sep 2010, 09:54
Rufname:
Wohnort: Saarbrücken

Tabellen im Hauptspeicher bearbeiten statt in DB auf Platte - Tabellen im Hauptspeicher bearbeiten statt in DB auf Platte

Nach oben
       Version: Office 2003

Hallo erstmal...

Aus Gründen der Performance will ich eine Tabelle ins Memory kopieren und dort bearbeiten, um sie dann anschließend wieder auf das Netzwerk/Platte zu speichern.

Ich stehe etwas auf dem Schlauch:
Wie erstelle ich eine Tabelle so, dass sie nicht in der DB sondern im Memory bleibt?

_________________
Gruß
Jürgen

Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie!
Weingeist
Im Profil kannst Du frei den Rang ändern


Verfasst am:
29. Sep 2010, 17:18
Rufname:


AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Also ob das tatsächlich schneller ist wage ich zu bezweifeln. Kommt halt extrem drauf an, was du überhaupt mit den Daten anstellst und bei was die Performance bescheiden ist. Volltextsuche inkl. ersetzen und so spässe könnte aber durchaus schneller sein.

Allerdings musst du dazu die Werte auch erstma aus der Tabelle auslesen.


Ansatz 1:
Packe die Backend-DB oder besser eine Temp-DB in eine RAM-Disk oder auch auf ne SSD. Da kannst Du nun via der Frontend TempTabellen erstellen die verdammt schnell sind.

Ansatz 2:
- Feldklasse für die Feldwerte (entweder eine flexible oder für jede Art Feld eine)
- Collection-Klasse für die Datensätze, welche die Felder aufnimmt
- Eine Handling-Klasse welche dir die jede Collection-Klasse der DS handelt

Viiiel Zeit fürs Testen... Punkt 1 + 2 nehme ich für Nicht-Datengebundene Formulare für Eingaben in die DB. Da ist aber nur immer ein Datensatz zu laden. Für ganze Tabellen ist das ziemlich grob. Und ob das tatsächlich schneller ist wage ich auch zu bezweifeln.

Ansatz 3:
- Versuche den ganzen Kram in Arrays abzulegen. Auch ziemlich heavy das sauber zu steuern. Könnte man aber auch über ne Klasse automatisieren.

Ansatz 4:
- Nimm dir SQL-Server. ;)


Was genau zu nehmen ist musst du selbst entscheiden. Vorher würde ich als Ansatz 0 aber versuchen ob du nicht die Performance mit Abfragen-Tuning etc. steigern kannst.
MAPWARE
Access Profi(l)neurotiker


Verfasst am:
30. Sep 2010, 13:06
Rufname:
Wohnort: Hannover

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Hi,
Tabellen befinden sich im Augenblick des Zugriffes natürlich im Arbeitsspeicher und werden durch extrem ausgefeilte Mechanismen bei Bedarf von den langsamen Medien nachgeladen und zurückgeschrieben. Eine Tabelle oder Abfrage im Arbeitsspeicher heisst Recordset, das wichtigste Objekt in Access, und ist netterweise schon fix und fertig programmiert, da musst Du nichts mehr dazuerfinden.
Das Optimierungspotential liegt in der Struktur der Abfragen und Tabellen.

_________________
Grüße
Marcus

Wer Controls nicht sinnvoll benennt, wird es später bereuen.
Weingeist
Im Profil kannst Du frei den Rang ändern


Verfasst am:
30. Sep 2010, 14:17
Rufname:

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Da hat er natürlich recht... müsste an 1. Stelle stehen! Das einfachste glatt vergessen. Shock Mad
KlausMz
Moderator Access


Verfasst am:
30. Sep 2010, 19:46
Rufname:
Wohnort: Irgendwo in der Pfalz


AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Hallo,
Zitat:
Ansatz 3: - Versuche den ganzen Kram in Arrays abzulegen.
dass das auch nur ansatzweise schneller ist stelle ich drastisch in Frage.
_________________
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
K_Mueller
Feldbereitsteller


Verfasst am:
30. Sep 2010, 20:37
Rufname:
Wohnort: Duisburg

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Hallo zusammen,

ich glaube es werden "Disconnected Recordsets" gesucht!?
Disconnected Recordsets
und So erstellen Sie ADO getrennte Recordsets in VBA / C + / Java
Die machen es wirklich einfach.

Gruß Klaus Müller

_________________
Win 98SE bis XP(e), Acc97 bis 03 (e), SQL-Server 2k (e), Replikation
PS: Bitte Feedback nicht vergessen!

Vorstellungskraft ist wichtiger als Wissen, denn Wissen ist begrenzt. (Albert, Einstein)
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
30. Sep 2010, 21:26
Rufname:

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Hallo,

SQL wurde gerade für Datenbanken erfunden, die sich auf Datenträgern befinden. Recordsets, auch ungebundene im Speicher, sind grundsätzlich immer langsamer. Was weniger an den Recordsets als am eher langsamen VBA liegt. Aber kein Recordset wird schneller sein als ein SQL-Befehl.

Da stimme ich Weingeist zu: Wenn überhaupt, kannst Du höchstens eine Datenbank in eine RAM-Disk auslagern, aber dann müßtest Du das auch mit dem virtuellen Speicher von Windows machen, denn der benutzt weiterhin Platte UND Speicher und wird durch eine große RAM-Disk eher noch öfter anspringen.

Eine optimale SQL-Abfrage, gute Indizes, optimale Datenstruktur - das bringt Performance. Ein Recordset sollte immer nur die letzte Wahl sein, wenn nichts mehr anderes geht.

Gruß

Christian
JMalberg
Es wird so langsam sinnig ...


Verfasst am:
01. Okt 2010, 12:11
Rufname:
Wohnort: Saarbrücken

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Danke erst mal!

Ich hole mal ein bisschen aus:

Ziel ist es einzeln Records einer Stücklistenstruktur nach Änderung zu ersetzen.
Es bestehen ~3.500 Stücklisten mit durchschnittlich 4 Positionen in der Stücklistentabelle (IDParent, rIDChild, mengen, zeiten) , woraus dann schließlich durch rekursive Auflösung der Stückliste eine reine Strukturtabelle (IDRoot, rID-Parent, rIDChild, sum_mengen, sum_zeiten,...) entsteht mit ~140.000 Records.in der Strukturtabelle ist also der inhalt eines TreeView nachgebildet, aussser dass statt einem Root-Knoten eben 3.500 bestehen.
Diese Erstellung der Struktur erfolgt wie geschrieben rekursiv und ist soweit stabil.

Aber...
Wird jetzt in einer untergeordneten Stückliste eine Position geändert/ergänzt/gelöscht lösche ich alle Stücklistenstrukturen in denen diese geänderte Position enthalten ist zur Sicherheit komplett und generiere sie erneut.
Dabei werden auch oft mal einige 10.000 Record gelöscht und wieder neu aufgebaut.
Als Singleuser geht dies bei der Netzwerklösung mit lokalen Clients noch ganz gut dauert aber auch zu Weilen mal 10min. Sobald ein 2. oder 3. diese Stücklisten ändert geht die Performance absolut in den Keller.

Nun war meine Idee die neu zu erstellenden Records lokal zu generieren und erst nach Abschluss in die ZielDB zu schreiben.

(Sorry, für das kurze Schreiben; bin Gipshand bedingt Linkshänder:))

PS: Bin nicht neu in Access unterwegs, sondern seit Acc1.1 seit 1996 unterwegs. Ihr könnt die Basics voraussetzen, ... ausser Klassenmodelle, mit denen stehe ich auf KriegsfußVery Happy

_________________
Gruß
Jürgen

Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie!
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
01. Okt 2010, 12:44
Rufname:

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Hallo,

prinzipiell kannst Du natürlich ein Disconnected Recordset erstellen, aber irgendwie klingt das ganze nach einer falschen Modellierung der TreeView. Warum einen ganzen Zweig neu erstellen, wenn Du nur ein Blatt ändern möchtest? Die TreeView unterstützt Drag & Drop und wenn Du statt eines Recordsets einfach ein Objektmodell aufbaust, brauchst Du im Zweifelsfall nur eine ID zu verändern, nämlich die ParentID. Eine ChildID oder RootID ist normalerweise in einem Baum nicht notwendig, da jedes Element immer genau ein Parent-Element hat, bis auf das Root-Element. Eine RootID oder eine ChildID kann höchstens hilfreich sein, aber notwendig ist sie nicht.
Bestes Beispiel für so eine Struktur ist die AdventureWorks Datenbank, in der die Organigrammstruktur des Personals mit einer einzigen ParentID beschrieben ist.

Verschieben: Die ParentID bekommt eine neue ParentID zugewiesen, von dem Zweig, wohin sie verschoben wird.
Hinzufügen: Der neue Datensatz bekommt die ID des Zweigs, in dem "Hinzufügen" angeklickt wurde.
Kopieren: Der kopierte Datensatz bekommt die ID des Zweigs als ParentID, in den er hineinkopiert wurde.
Löschen: Hat das Element selbst Child-Elemente, sammelt man deren IDs ein und löscht den Zweig, ansonsten eben nur das Element.

Wozu also den Baum neu aufbauen?

Im Tips&Tricks-Forum habe ich mal so einen TreeView anhand der AdventureWorks-Datenbank aufgebaut.

Ein Bearbeiten des Baums im Speicher ist insofern schlecht, weil dann ein Benutzer viele Änderungen machen kann, bevor er sie hochlädt, und dann mußt Du einen ausgefeilten Algorithmus haben, um die Konflikte mit den Änderungen aller anderen User zu handlen.... was bei einer linearen Struktur noch halbwegs einfach geht, wird dann bei einem Baum richtig kompliziert.

Objektmodell: Wo ist da das Problem? Das ist nur eine variablentechnische Abbildung Deiner Baumstruktur. Und das Objektmodell kann alle Deine Probleme erledigen, da jedes Objekt seine eigenen Funktionen und Daten mitbekommen kann, um es zu verschieben, löschen usw.
GERADE für eine Baumstruktur gibt es nix Besseres als Klassenmodule!

Gruß

Christian
JMalberg
Es wird so langsam sinnig ...


Verfasst am:
01. Okt 2010, 13:08
Rufname:
Wohnort: Saarbrücken

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Ok, verstanden.

Ich denke dass die Lösung vom Thema abweicht und es sinnvoll wäre ein eigenes Thema "Treeview-Daten als Tabelle" o.ä. zu öffnen.

OK?

_________________
Gruß
Jürgen

Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie!
Weingeist
Im Profil kannst Du frei den Rang ändern


Verfasst am:
03. Okt 2010, 14:53
Rufname:

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

@KlausMZ: Nun, es kommt immer drauf an was man macht. Ausgelagert in eine DLL dürfte der Zugriff auf die Daten schon sehr zackig sein.

@Jmalberg:
Nach der jetzigen Erklärung wäre wohl das richtige Stichwort Nested Sets. Die sind unglaublich schnell aber auch mitunter nicht ganz trivial zum handhaben. Mit ner gscheiten Klasse geht das aber auch. Ist auch etwas was mir noch bevorsteht, habe aber noch keine Zeit gefunden es zu realisieren.

Bissel Lektüre: http://www.klempert.de/nested_sets/#box1

Der Baum ist ziemlich anfällig, also Fehlmanipulationen NICHT erlaubt, dann kannst schnell nen Berg Datenmüll haben. Du sägst quasi immer Äste ab, isses nen dicker, sind alle kleinen auch Futsch. Könntest du aber mit der Erhaltung der ChildParent Felder für einen solchen Fall abfangen, indem du dann die ID's neu erstellst. Darf aber nur der Notnagel sein, sonst bist immer am basteln.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
03. Okt 2010, 18:31
Rufname:

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Hallo Weingeist,

die "Nested Sets"-Theorie kannte ich auch noch nicht, spannender Artikel - könnte in einigen Fällen interessant sein, besonders auch der Hinweis, größere Bäume in kleinere aufzuteilen. Eine Kombination mit dem Parent-Modell würde ich allerdings auch in jedem Fall verwenden, da das eine gute Absicherung gegen fehlerhafte Updates im Nested-Modell ist - und das Updaten im Parent-Modell bedeutend einfacher ist, da etwa das Verschieben eines Zweiges nur das Ändern einer ID bedeutet, wohingegen beim Nested-Modell, wie ja dort so schön beschrieben, im ungünstigsten Fall das Ändern des gesamten Baumes nötig ist.
Und genau da sehe ich auch die größte Schwachstelle dieses Modells: In einer Multi-User-Umgebung, in der viele Leute an dem Baum "herumschnippeln", könnte die Performance bei schreibenden Zugriffen schnell in den Keller gehen, besonders wenn konkurrierende Schreibzugriffe (aus modelltechnischen Gründen logisch) komplett gesperrt werden müssen: Wenn 20 User warten, weil 1 User die Tabelle gesperrt hat, könnte das auch für einen lesenden Zugriff Performance-Verluste bedeuten. Die im Artikel angegebenen Zeiten mögen sicherlich stimmen für eine einfache, lokale Tabelle ohne Mehrbenutzerumgebung, aber ob das genannte Beispiel "Diskussionsforum" mit einem "gut besuchten Forum" dann immer noch das Parent-Modell in der Performance schlägt, ist fraglich. Zum Beispiel würde man im Diskussionsforum ja auch normalerweise nicht den kompletten Baum einlesen wollen, sondern i.d.R. nur einen Thread mit seinen unterschiedlichen Verzweigungen.

Fragt sich auch, wie der Autor die Zeiten für Rekursion ermittelt hat, ich weiß nicht, ob MySQL rekursive Abfragen unterstützt? In SQL Server gibt es seit 2005 die Möglichkeit, und da wird die Performance sicherlich auch ziemlich gut sein (hatte noch nicht oft das Vergnügen, rekursive SQL-Abfragen zu schreiben). Bei Rekursion per Programmiersprache dauert es natürlich um etliches länger (egal, welche Programmiersprache) als in SQL.

Auf jeden Fall dürfen bei dem Nested-Modell beim Schreiben keinerlei Fehler geschehen, muß man sehr sauber programmieren, damit man nicht einen Haufen unzusammenhängender Elemente hinterläßt, deren Struktur man ohne zusätzliche Parent-ID wohl dann auch nicht mehr zusammenbekommt.

Trotz allem - interessante Idee...lohnt sich, mal weiter drüber nachzudenken. Danke für den Link!

Gruß

Christian
Weingeist
Im Profil kannst Du frei den Rang ändern


Verfasst am:
11. Okt 2010, 21:16
Rufname:

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Das Modell wird meines Wissens in den meisten grossen Forensoftwares angewendet, weil die meisten Zugriffe eben gelesen und nicht geschrieben werden. Wenn man das gscheit macht, gibts auch keine Fehler. In Access bietet ADO und auch DAO gute Mittel (Transaktion), bei einem Fehler einen Rollback durchzuführen.

Und so wie ich das verstanden habe, sinkt bei seinem Problem vor allem die Performance beim lesen in den Keller (wenn es nicht gerade Log-DB's sind, sind die meisten Zugriffe eh lesend, bei einem Baum ist das fast immer sehr langsam, sobald ausgewertet werden muss) und die vielen Daten werden periodisch hinzugefügt. Die neuen 'Äste' eintragen geht auch bei vielen Datensätzen sehr schnell, weil bei den anderen nur ein paar Nummer ersetzt werden müssen. 'Nur' den Lock braucht man eben. Kann man aber auch lösen wenn man nicht überall Datengebunden arbeit, was in Mehrbenutzerumgebungen in Access eh problematisch ist.

Das ganze basiert alles auf simpelsten SQL-Befehlen. Lediglich in deren automatischen Generierung liegt die Schwierigkeit.

Ich würde das in Access ungefähr so angehen:
- Datenbearbeitung nur mit ungebundenen Formularen, also Ablage im Speicher
- Anlegen einer "Lock-Tabelle" in welcher man gezielt Locks für Dateninput ablegen kann. Zum Beispiel mit 1: nur noch lesen erlaubt. 2: Nix mehr erlaubt.
User wird entweder mit einer Meldung abgespeist oder mit ner Sanduhr.
- Status 1 heisst der User welcher die inputs fahren will, schickt einen Lock, das die Daten nicht mehr geändert werden dürfen. Dann werden alle SQL-Befehle generiert, im Ram gehalten und der Lock 2 gesendet. Dann darf kein Zugriff mehr erfolgen. Alle SQL-Befehle werden anschliessend in einer Transaktion abgehandelt und am Ende die Locks wieder aufgehoben.

Ich bin sicher, auch mit sehr vielen Inputs ist das rasend schnell. Auch in Access.
JMalberg
Es wird so langsam sinnig ...


Verfasst am:
12. Okt 2010, 14:45
Rufname:
Wohnort: Saarbrücken

AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Hi BitSqueezer, Weingeist,

die Nested Sets sind mir auch schon vor einiger Zeit unter gekommen, aber eben das Problem der Multiuserfähigkeit konnte ich noch nicht lösen.
Meine Idee ist es eben auch alle betroffenen Record in der DB zu markieren und dann lokal im Recordset die Struktur aufzubauen. Das scheitert aber mMn am Aufwand in der DB alle Änderungen abzufangen, die ein anderer User ebenfalls tätigen will.
Dann wäre eine Strukturänderung eine pure Singelusertätigkeit die im Batch (wie anno 1970) nacheinander abgearbeitet wird.
Dann wäre es auch schnurz ob es via Nested Sets oder rekursive Parent-Child gemacht wird, lediglich die Tabellenlänge ist mit Nested Sets geringer. Ist die Struktur mal aufgebaut ist der Zugriff via SQL rasend schnell.

... es könnte so einfach sein, isses aber nicht (Zitat einer deutschen Sprechgesangkapelle)

_________________
Gruß
Jürgen

Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie!
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
12. Okt 2010, 15:28
Rufname:


AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla - AW: Tabellen im Hauptspeicher bearbeiten statt in DB auf Pla

Nach oben
       Version: Office 2003

Hallo zusammen,

genau die Updatefähigkeit ist das große Problem bei Nested Sets, eben weil im schlimmsten Fall der gesamte Baum geändert werden müßte, was eine Verarbeitung für Mehrbenutzerumgebungen fast unmöglich macht (man kann nicht "mal eben" die ganze Tabelle für alle anderen User sperren, wenn es viele User sind).

Darum fand ich die Idee von dem Link oben interessanter, eben nicht alle Datensätze mit einzuschließen, sondern die Struktur in viele kleinere zu unterteilen. Wie bei der Forensoftware, die etwa nur einen einzigen Thread als einen Baum betrachten muß, was relativ wenige Datensätze sind, und nicht die kompletten Datensätze. Da hier eben auch nicht so viel geschrieben wird, kann man bequem auf diese Weise arbeiten.
Wenn jetzt ein Mod einen Thread auseinanderschneidet, bilden sich zwei getrennte Bäume, wenn er einen Thread an einen anderen anhängt, müssen auch nur die Elemente dieser beiden Threads erneuert werden, da ja nicht so viele Leute schreiben wie lesen, ist das kein Problem, alle Elemente beider Threads für den Update-Zeitraum zu sperren.

In einer Strukturtabelle wie der Personaltabelle aus der Nordwind-Datenbank sieht die Sache ganz anders aus. Unter Umständen kann man sich in einer so großen Struktur damit behelfen, Ebenen zu definieren, bis zu denen ein Baum gilt und ab dem ein neuer Baum anfängt (mit zwei zusätzlichen Feldern nach dem Nested-Prinzip je zusätzlicher Ebene). Dann müßten die Updates nur innerhalb einer Ebene stattfinden. Ist aber nur eine theoretische Idee, ob das so auch in der Praxis funktionieren könnte, weiß ich nicht, wahrscheinlich auch abhängig von den Daten.

Gruß

Christian
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Gehe zu Seite 1, 2  Weiter
Diese Seite Freunden empfehlen

Seite 1 von 2
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Tabellen & Abfragen: Datenabgleich gleicher Tabellen 5 Gast 1120 30. Jul 2004, 09:27
Willi Wipp Datenabgleich gleicher Tabellen
Keine neuen Beiträge Access Tabellen & Abfragen: aufsummieren 2er tabellen 1 micky1409 1025 17. Jul 2004, 23:43
faßnacht(IT); aufsummieren 2er tabellen
Keine neuen Beiträge Access Tabellen & Abfragen: 2 gleiche Tabellen in 2 verschiedenen DB verknüpfen 2 mondi 1015 23. Jun 2004, 10:10
mondi 2 gleiche Tabellen in 2 verschiedenen DB verknüpfen
Keine neuen Beiträge Access Tabellen & Abfragen: tabellen mit einander verbinden 6 TeeJay 1737 16. Jun 2004, 11:15
TeeJay tabellen mit einander verbinden
Keine neuen Beiträge Access Tabellen & Abfragen: Daten aus mehreren Tabellen in einer Gesamttabelle richtig e 5 hoschi 1573 04. Jun 2004, 13:01
stpimi Daten aus mehreren Tabellen in einer Gesamttabelle richtig e
Keine neuen Beiträge Access Tabellen & Abfragen: 2 tabellen vergleichen 4 Lordoo88 1555 03. Jun 2004, 16:43
Lordoo88 2 tabellen vergleichen
Keine neuen Beiträge Access Tabellen & Abfragen: Zwei Tabellen zusammenfügen und Nullwerte überschreiben 1 m.hataj 1304 13. Mai 2004, 18:10
faßnacht(IT); Zwei Tabellen zusammenfügen und Nullwerte überschreiben
Keine neuen Beiträge Access Tabellen & Abfragen: Abfrage erstelen, die zwei tabellen vergleicht 2 pucky 802 27. Apr 2004, 10:53
ProLogistik Abfrage erstelen, die zwei tabellen vergleicht
Keine neuen Beiträge Access Tabellen & Abfragen: Abgleich von 2 tabellen in access 2003 4 Fierce 1719 16. Apr 2004, 08:27
el_gomero Abgleich von 2 tabellen in access 2003
Keine neuen Beiträge Access Tabellen & Abfragen: neue Tabellen erzeugen; kopieren 7 DiplomandSPS 1323 25. März 2004, 10:01
fridgenep neue Tabellen erzeugen; kopieren
Keine neuen Beiträge Access Tabellen & Abfragen: 2 Tabellen in eine neue 18 Gast 2365 23. März 2004, 10:44
mrd 2 Tabellen in eine neue
Keine neuen Beiträge Access Tabellen & Abfragen: Nach Abfrage nicht mehr möglich in DB zu schreiben??!! 1 El_Kloncks 498 18. März 2004, 09:59
lothi Nach Abfrage nicht mehr möglich in DB zu schreiben??!!
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: HTML Editor Forum