philipp-schoene Geschrieben 6. August 2008 Autor Geschrieben 6. August 2008 Ich würde mich da wirklich in ein Gespräch mit meinem Chef begeben und ihm das im Detail schildern. Zum Thema Datawarehouse. Warum verkaufst Du ihnen nicht ein Datawarehouse Konzept und mach exemplarisch dies an deinem Beispiel der Buchungen fest: Lass Dir nen neuen User in KHK anlegen, der nur Daten lesen kanninstallier den ODBC TreiberVerknüpfe die Tabellen die Du brauchsterstelle Deine Auswertunge mit nen paar schönen Bildchen z.B. hänge an Access noch Excel drangeh zu Deinem Chef, installiere in seinem Beisein den ODBC Treiber und mach die Access Datenbank auf und zeige ihm was man machen kann Dies werde ich machen. Diese Woche ist er weg und dann die zwei Wochen habe ich mir Urlaub genommen. Ich bitte Dich zu informieren was ein ERD ist. Ohne dass Du Beziehungen zwischen Deine Tabellen erkennst, kannst Du sie nicht auswerten. Denn wie hängen z.B. Konten_HA und Werte_DL zusammen? Deswegen die Bitte schau Dir die Originaltabellen an und mit Visio kannst Du Dir die Beziehungen z.B. graphisch darstellen lassen (sofern dass die Datenbank das unterstützt) Ich habe dich so verstanden, dass du die Beziehungen, die in Access eingestellt sind, meinst. Natürlich gibt es eine logische Beziehung: Aus der werte-Tabelle gibt es ein Konto, das dazugehört. Also eine 1:n-Beziehung Visio gibt es hier nicht. Aber wenn es nur zum angucken geht, brauche ich es auch nciht unbedingt. Dazu meine Frage was willst Du? Sollen wir Dir jetzt die VBA Befehle und die einzelnen Schritte diktieren, damit Du unsere Leistung als Deine verkaufen kannst? Phil Ich habe in dem Abschnitt nicht geschrieben, dass ich was will. Und ich möchte auch auf keinen Fall die Leistung unter falschen Namen verkaufen. Ich bin hier Zivi (deswegen bin ich auch nur noch 3 Monate hier) und verdiene an dem Projekt nichts. Ich habe durchaus auch hier eigene Lösungen. Grad seit gestern habe ich schon alleine Fortschritte gemacht. Solange ich meinen Chef nicht fragen kann, mache ich ein wenig weiter, wie es bisher geplant war: ALso ich möchte die drei Tabellen zu einer zusammenfassen. Kann ich mit SQL die Tabelle Konten mit den Daten füllen? Also ich hatte den INSERT-Befehl. Denn zunächst ist die Tabelle leer. Aber ich habe schnell gemerkt, dass das nicht gut, ist, wenn ich die Tabelle ein 2. Mal einlese. Das werden die gleichen daten nocheinmal angehängt. wie kann ich das in SQL machen: Wenn der Datensatz nicht da ist neu schreiben und wenn er da ist nur aktualisieren. Wenn dies der UPDATE-Befehl ist: Ich habe es mit DoCmd.RunSQL "UPDATE Konten SET (Kontonummer = import_Konten_Domladen)" Access meldet einen Sytax Fehler. Ich musste bisher noch nie eine Tabelle einer Datenbank in eine andere einfügen. Wenn ich alle drei in einer Tabelle habe, möchte ich die import-Tabelle wieder löschen. Sie diene n ur zur zweifelsfreien Zuordnug der Mandantennummer. Weiterarbeiten, werde ich nur mit der Tabelle Konten. Zitieren
flashpixx Geschrieben 6. August 2008 Geschrieben 6. August 2008 Visio gibt es hier nicht. Aber wenn es nur zum angucken geht, brauche ich es auch nciht unbedingt. Du hättest auch mal Google bemühen können: DbVisualizer - The Universal Database Tool ALso ich möchte die drei Tabellen zu einer zusammenfassen. Kann ich mit SQL die Tabelle Konten mit den Daten füllen? Also ich hatte den INSERT-Befehl. Denn zunächst ist die Tabelle leer. Aber ich habe schnell gemerkt, dass das nicht gut, ist, wenn ich die Tabelle ein 2. Mal einlese. Das werden die gleichen daten nocheinmal angehängt. wie kann ich das in SQL machen: Wenn der Datensatz nicht da ist neu schreiben und wenn er da ist nur aktualisieren. Wenn dies der UPDATE-Befehl ist: Ich habe es mit DoCmd.RunSQL "UPDATE Konten SET (Kontonummer = import_Konten_Domladen)" Access meldet einen Sytax Fehler. Ich musste bisher noch nie eine Tabelle einer Datenbank in eine andere einfügen. Das ist klar und auch absolut so korrekt Wenn ich alle drei in einer Tabelle habe, möchte ich die import-Tabelle wieder löschen. Sie diene n ur zur zweifelsfreien Zuordnug der Mandantennummer. Weiterarbeiten, werde ich nur mit der Tabelle Konten. Ich wiederhole mich, schaut Dir SQL an !! Du möchtest einen Select über eine bestimmte Anzahl von Tabellen machen. Dazu hatte ich nun schon mehrfach Dir gesagt, erstelle Dir eine Abfrage / View in der Du einen Select in passender Form hinterlegt. Du benötigst dazu: Relationen / Beziehung zwischen den TabellenBeziehung zwischen Daten und Mandanten (obwohl das mit Punkt 1 äquivalent ist)eine Abfrageeinen Select mit entsprechenden Join Verknüpfungen (ggf. noch die Einschränkungen)diese Abfrage nimmst Du dann nun für Deinen Bericht (und machst was schönes draus) Das Löschen von Tabellen ist absoluter Mist und nicht im Sinne des Erfinders. Du hast in einem anderen DBMS nicht unbedingt die Berechtigung einfach so ein paar Tabellen zu löschen oder zu erzeugen, sondern Du kannst nur die Daten manipulieren bzw abfragen. Entwerfe ein vernünftiges Konzept und keine "Frickellösung". Phil Zitieren
philipp-schoene Geschrieben 7. August 2008 Autor Geschrieben 7. August 2008 (bearbeitet) Du hättest auch mal Google bemühen können: DbVisualizer - The Universal Database Tool Mehr als die Funktion die Access mitbringt kann es doch nicht sein. Das ich nur dreimal je zwei Tabellen in Relation bringen muss, werde ich das so gerade noch im Kopf hinbekommen. Deswegen habe ich mich nicht darum gekümmert. wäre schön, wenn du mit sagen könntest, wie ich das lösen könnte. Auch wenn es nicht die von dir gewollte Lösung ist. Im Moment muss ich die Variante weiter machen, da ich den zuständigen Mitarbeiter nicht erreichen kann. Nach dem Gespäch mit ihm kann man die andere Lösungsmethode in Angriff nehmen. Also nochmal meine Frage: Kann SQL die Daten der drei Tabellen in einer zusammen fassen? Warum habe ich die drei Tabellen überhaupt importiert und angelegt? Da ich nicht so Fit in der Datenbankprogrammierung bin, habe ich alles in kleinere Schritte unterteilt. Außerdem muss der Mandant eindeutig zugeordnet werden. Wenn ich das in der zusammengefassten Tabelle machen würde, könnte es meiner Ansicht nach zu Fehlern kommen wenn ein Mandant nicht eingetragen ist. Denn in der zusammengefassten Tabelle kann man die Konten nicht mehr auseinander halten. Weil es ein Zwischenschritt ist, möchte ich die Tabelle auch wieder löschen. Dass es elegantere Methoden geben mag, ist mir bewusst! Oder kann man die die drei Tabellen mit einer Abfrage besser zusammenfügen? nochmal, was ich als Ziel habe: Da ich die drei Mandanten zusammen auswerten soll, muss ich mir erstmal Rohdaten schaffen, mit denen ich dann die Auswertung machen kann. Sehe ich das richtig? Wo ich ein Problem sehe: Wenn sich Konten ändern (Was eigentlich selten vorkommt) und Werte auf das Konto verweisen, wird das schief gehen. Ich kenne die Struktur der Datenbank von Sage KHK nicht. Dort werden die Konten so hinterlegt sein, dass man nach Jahren noch die Struktur von damals abfragen kann denke ich --> Dies spricht wieder für die ODBC-Lösung direkt an Sage KHK. Wenn ich mit dem Chef rede sollten einige meiner Fragen klar sein: Muss man die Konten überhaupt in einer Tabelle zusammen fassen? Ist es nicht besser die Abfrage entsprechend zu formulieren? Man muss dann nur dazuschreiben, aus Welcher Tabelle die Daten kommen. Was haltet ihr davon? Bearbeitet 7. August 2008 von philipp-schoene Zitieren
flashpixx Geschrieben 7. August 2008 Geschrieben 7. August 2008 (bearbeitet) Ich lese Deine Post sehr aufmerksam und ich versuche Dir Hinweise zu geben, was Du Dir bitte anschauen solltest. Ich empfinde es mehr als unhöflich hier mehrfach immer wieder zu betonen was Du möchtest. Ebenso setze ich in meiner Beschreibung grundlegende Kenntnisse in SQL und dem generellen Datenbankverständnis voraus, die Du anscheinend ignorierst. Ich bitte Dich noch einmal Dir die Grundkenntnisse von einer Datenbank, hierzu gehören SQL (DDL und DML), Begriffe wie Relationen / Verknüpfungen / Beziehungen / PK & FK, Schnittstellen (ODBC) anzueignen, damit wir eine Basis haben auf der man sinnvoll diskutieren kann. Mehr als die Funktion die Access mitbringt kann es doch nicht sein. Das ich nur dreimal je zwei Tabellen in Relation bringen muss, werde ich das so gerade noch im Kopf hinbekommen. Deswegen habe ich mich nicht darum gekümmert. Ich gehe davon aus, Dir ist der Begriff "Reverse Engineering" bekannt. wäre schön, wenn du mit sagen könntest, wie ich das lösen könnte. Formuliere Deine Abfrage in korrekter Form Also nochmal meine Frage: Kann SQL die Daten der drei Tabellen in einer zusammen fassen? Mache einen "Insert .. Select" Warum habe ich die drei Tabellen überhaupt importiert und angelegt? Da ich nicht so Fit in der Datenbankprogrammierung bin, habe ich alles in kleinere Schritte unterteilt. Meine Glaskugel ist in der Spüle, das kann ich Dir auch nicht sagen warum Du das machst. Ich würde es nicht machen. Außerdem muss der Mandant eindeutig zugeordnet werden. Wenn ich das in der zusammengefassten Tabelle machen würde, könnte es meiner Ansicht nach zu Fehlern kommen wenn ein Mandant nicht eingetragen ist. Denn in der zusammengefassten Tabelle kann man die Konten nicht mehr auseinander halten. Dir ist der Begriff des "Schlüssel" klar !? Ein Schlüssel kann einen Datensatz eindeutig identifizieren, sofern er "unique" ist. Der Primärschlüssel einer Tabelle ist dies. Oder kann man die die drei Tabellen mit einer Abfrage besser zusammenfügen? Du möchtest Dich hier über "Joins" informieren (und ich bitte noch einmal inständig dies zu tun) nochmal, was ich als Ziel habe: Da ich die drei Mandanten zusammen auswerten soll, muss ich mir erstmal Rohdaten schaffen, mit denen ich dann die Auswertung machen kann. Sehe ich das richtig? Mir ist Dein Ziel durchaus bekannt! Wo ich ein Problem sehe: Wenn sich Konten ändern (Was eigentlich selten vorkommt) und Werte auf das Konto verweisen, wird das schief gehen. Eben und deswegen arbeitet man direkt auf den Daten bzw. auf einer definierten Struktur. Deine ursprüngliche Datenbank hat eine definierte Struktur, also arbeite dort und lese nur die Daten, dann wenn Du eben Deine Auswertung erzeugen willst Ich kenne die Struktur der Datenbank von Sage KHK nicht. Ich habe Dir oben den Begriff "Reverse Engineering" genannt und Dir dazu ein Tool empfohlen mit dem Du die Struktur der für Dich notwendigen Tabellen ermitteln kannst. Dort werden die Konten so hinterlegt sein, dass man nach Jahren noch die Struktur von damals abfragen kann denke ich --> Dies spricht wieder für die ODBC-Lösung direkt an Sage KHK. Weshalb? Ich kann meine Daten über eine Bedingung einschränken. Wenn ich alle von 2003 haben will, dann bekomme ich die auch direkt aus der Datenbank. Wenn ich mit dem Chef rede sollten einige meiner Fragen klar sein: Muss man die Konten überhaupt in einer Tabelle zusammen fassen? Ist es nicht besser die Abfrage entsprechend zu formulieren? Man muss dann nur dazuschreiben, aus Welcher Tabelle die Daten kommen. Was haltet ihr davon? Das ist keine dem Datenbankkonzept entsprechende Lösung. Ich habe Tabellen und Schlüssel und kann damit Relationen erstellen, warum soll ich mir Tabellennamen in einen Datensatz reinschreiben? Die Frage ist, finde ich beantwortet Zwischen den jeweiligen Konten/Werte-Tabellen besteht eine 1:n Beziehung Du sollst nicht eine Beziehung betrachten, sondern alle, die für Deine Auswertung relevant sind. Hier fehlt die Beziehung Mandant-Konten Meinst du eine Abfrage, die die von mir oben erwähnen "Rohdaten" enthält? Unter Rohdaten ist eine Art Vorlage aus denen ich mit SQL jeden erdenklichen Wert rausholen kann. Bitte schaue Dir SQL an, es ermöglicht Dir aus einer oder auch datenbankübergreifend aus jeder Tabelle / jedem Feld Werte zu lesen, zu löschen oder zu manipulieren (Sum- / Avg-Funktionen). Die Bedingungen sind, dass Du eine Verbindung zur Datenbank hast (über einen ODBC Treiber), eine Programmiersprache über die Du den Treiber ansprichst (hier VBA) und die Struktur der Tabellen / Datenbank kennst, damit Du weißt, wo und welcher Wert steht. Zur Querinformation: Access macht intern nichts anderes (nur dass der Treiber nen anderer ist). Erstell Dir bitte einmal per Mausschubsen eine Abfrage und schau Dir diese im Entwurf an. Ich bitte Dich hier noch einmal: Schaue Dir die Grundlagen von Datenbanken an, schaue Dir an, was SQL ist und wie man es verwendet. Überlege Dir ein sinnvolles Konzept für Dein Problem. Ob Du nun innerhalb Deiner Accessdatenbank bleibst und ohne ODBC Verbindung zu KHK arbeitest oder direkt auf KHK die Daten ausliest, ist völlig irrelevant, denn der Unterschied besteht nur in der Formulierung des SQL Selects. Du kannst doch zuerst einmal die Auswertung innerhalb von Access erstellen. Wenn diese fertig ist, dann musst Du nur die ODBC Quelle an Access anbinden und den SQL Select etwas anpassen und schon läuft Deine Auswertung auf KHK. Aus Benutzersicht poppt dann ein Fenster auf in dem das Jahr zu dem ich die Auswertung haben möchte, abgefragt wird und danach kommt der druckfertige Bericht heraus. Ich verweise Dich mal auf Deinen eigenen Thread in Deinem Forum: http://forum.philipp-schoene.de/computer/internet/293-news-script/ Phil Bearbeitet 7. August 2008 von flashpixx Zitieren
philipp-schoene Geschrieben 8. August 2008 Autor Geschrieben 8. August 2008 Meine Glaskugel ist in der Spüle, das kann ich Dir auch nicht sagen warum Du das machst. Ich würde es nicht machen. Wenn du meinen Satz selbst in Einzelteile zerstückelst, dann bist du selbst Schuld. Ich habe eine Frage gestellt, die ich selbst beantwortet habe. Dir ist der Begriff des "Schlüssel" klar !? Ein Schlüssel kann einen Datensatz eindeutig identifizieren, sofern er "unique" ist. Der Primärschlüssel einer Tabelle ist dies. Ich glaub es liegt ein Missverständnis vor. Also klar kenne ich Schlüssel. Mit diesen kann man jeden Datensatz identifizieren. Ich meine das so: die Kontonummern der Tabellen Konten von PP, HA und PP sind teilweise gleich. Die muss ich ja nun auseinander halten. Aber dieses Problem ist ja hinfällig, wenn ich die drei Tabellen nicht in eine zusammenführen möchte. Dies macht man ja nicht, hast du gesagt. Weshalb? Ich kann meine Daten über eine Bedingung einschränken. Wenn ich alle von 2003 haben will, dann bekomme ich die auch direkt aus der Datenbank. Genau das meine ich doch!!! Wieder das gleiche wie oben. Wenn du den Abschnitt nicht komplett beachtest. Egal. Mache dir keinen Vorwurf. Du sollst nicht eine Beziehung betrachten, sondern alle, die für Deine Auswertung relevant sind. Hier fehlt die Beziehung Mandant-Konten Bitte überprüfe mich mal, ob ich das nun richtig Verstanden habe. (Ich lerne ja gerne was dazu) Auswertung - Mandant 1:n Mandant - Konten 1:n Konten - Werte 1:n Ob man erstes in Beziehung setzen kann weiß ich nicht so genau. Vielleicht kannst mir da auch korrigieren. Bitte schaue Dir SQL an, es ermöglicht Dir aus einer oder auch datenbankübergreifend aus jeder Tabelle / jedem Feld Werte zu lesen, zu löschen oder zu manipulieren (Sum- / Avg-Funktionen). Die Bedingungen sind, dass Du eine Verbindung zur Datenbank hast (über einen ODBC Treiber), eine Programmiersprache über die Du den Treiber ansprichst (hier VBA) und die Struktur der Tabellen / Datenbank kennst, damit Du weißt, wo und welcher Wert steht. [...] Du kannst doch zuerst einmal die Auswertung innerhalb von Access erstellen. Wenn diese fertig ist, dann musst Du nur die ODBC Quelle an Access anbinden und den SQL Select etwas anpassen und schon läuft Deine Auswertung auf KHK. Aus Benutzersicht poppt dann ein Fenster auf in dem das Jahr zu dem ich die Auswertung haben möchte, abgefragt wird und danach kommt der druckfertige Bericht heraus. Ich habe vor es bei der Entwicklung mit einer lokalen DB zu machen. Aber sehe ich es richtig, dass ich einen gesamten Export aller Daten in eine Datenbank brauche? Ich habe je eine Datenbank mit den jeweils schon erwähnten 6 Tabellen. Ist die die falsche Vorlage? (Also für die Lösung des Jahrübergreifenden Berichts) Ich verweise Dich mal auf Deinen eigenen Thread in Deinem Forum Was soll ich denn da? Wenn man eigene Texte liest findet man keine Fehler. Also weiß ich nicht, wieso du mich auf diesen Beitrag verweist. Sorry, ich nicht böse gemeint. Ich habe bisher viel gelernt. Schonmal zwischendurch vielen Dank für deine Hilfe Zitieren
flashpixx Geschrieben 8. August 2008 Geschrieben 8. August 2008 (bearbeitet) Ich glaub es liegt ein Missverständnis vor. Also klar kenne ich Schlüssel. Mit diesen kann man jeden Datensatz identifizieren. Ich meine das so: die Kontonummern der Tabellen Konten von PP, HA und PP sind teilweise gleich. Die muss ich ja nun auseinander halten. Aber dieses Problem ist ja hinfällig, wenn ich die drei Tabellen nicht in eine zusammenführen möchte. Dies macht man ja nicht, hast du gesagt. Mach mal hier folgenden Gedankenschritt: Du hast eine Tabelle (X) auf der irgendwelche Daten stehen. Diese Tabelle hat einen PK. Nun hast Du wo anders noch eine Tabelle (Y) die zu X in einer 1:n Relation steht. Dann hast Du noch eine dritte Tabelle (Z) die auch zu X in 1:n steht. Nun willst Du diese 3 Tabellen "verwursten", sprich eine daraus machen. Wie muss sich dann zwingend der PK von unserer neuen Tabelle zusammen setzen? PK von Z bzw Y knallt, du könntest Duplikate in den Schlüssel haben. Was identifiziert Deine Datensätze? Doch eigentlich unsere Tabelle X + das was auf Z bzw Y steht. Sprich wenn Du das korrekt auseinander halten willst, dann setzt der PK Deiner neuen Tabelle aus dem PK der "führenden" (der 1er in Relation) + dem PK der "nachfolgenden" (der n in der Relation) zusammen. Sprich in Deinem konkreten Fall: Mandenten PK + PK der jeweiligen Buchungstabelle = PK Deiner gesamten Tabelle. Die Identifizierung immer mit Mandant. Aber Achtung: ich weiß nicht, wie der Export aussieht. Gerade bei Buchungssachen sind die PKs manchmal bisschen fies designed. Bitte überprüfe mich mal, ob ich das nun richtig Verstanden habe. (Ich lerne ja gerne was dazu) Auswertung - Mandant 1:n Mandant - Konten 1:n Konten - Werte 1:n Ob man erstes in Beziehung setzen kann weiß ich nicht so genau. Vielleicht kannst mir da auch korrigieren. Kann ich leider nicht, mir fehlt die Datenbank. Ich muss mir die Beziehungen anschauen und dann kann man das auch sagen. Deswegen die Bitte ein reverse engineering zu machen und sich es anzuschauen. Wenn es innerhalb von Access ist, dann gibt es da die Möglichkeit (ich glaube das heißt Beziehungen) sich eben die Verknüpfungen anzuschauen. Als Anmerkung, hast Du eine Entity "Auswertung" ? Du hast hier noch nicht verstanden was Ziel Deiner Aufgabe ist. Du hast physikalische Tabellen und sollt darauf eine Sicht der Daten erstellen, diese Sicht der Daten existiert aber nicht im Datenbankmodell. Sichten, d.h. die Sicht für Deine Auswertung ist gedanklich nur so lange vorhanden, so lange Du Deinen Bericht verwendest Ich habe vor es bei der Entwicklung mit einer lokalen DB zu machen. Aber sehe ich es richtig, dass ich einen gesamten Export aller Daten in eine Datenbank brauche? Das kann man nicht pauschal sagen. Es kommt auf Deine konkrete Problemstellung an. Evtl reichen ein "paar" Tabellen, evtl brauchst Du aber auch "einige paar" mehr. Das siehst Du aber daran wie das reverse engineering ausällt, welche Tabelle mit welcher in Beziehung steht. Um eben genau das Problem zu vermeiden, dass Du nach und nach alle Tabellen kopierst, mach es doch direkt auf der Datenbank eben via ODBC, damit hast Du eh alles verfügbar und kannst es, wenn Du es benötigst, nachlesen (der Ratschlag kommt wirklich aus dem Berufsleben, denn es wird immer den Fall geben, wo es heißt "kann man nicht doch noch....." - sprich mach Dir ein Konzept, dass so etwas mit minimalen Änderungen schnell "erschlägt") Ich habe je eine Datenbank mit den jeweils schon erwähnten 6 Tabellen. Ist die die falsche Vorlage? (Also für die Lösung des Jahrübergreifenden Berichts) Siehe oben, eine pauschale Antwort kann ich Dir nicht nennen. Ich kenne KHK nur vom "Hören-Sagen", ebenfalls sitze ich nicht vor dem konkreten System und sehe die Daten (Hinweis der Glaskugel). Du musst selbst bewerten was Du brauchst und was nicht. Was soll ich denn da? Wenn man eigene Texte liest findet man keine Fehler. Also weiß ich nicht, wieso du mich auf diesen Beitrag verweist. Sorry, ich nicht böse gemeint. Das war der Hinweis auf SQL. Überlege Dir noch einmal was Du dort gemacht hast (also was war Dein Ziel und was hast Du in SQL gemacht). Im Grunde ist das hier absolut die gleiche Problematik nur eben "komplexer". Du hast nicht mehr eine Tabelle sondern 6 und Du willst nicht mehr 10 Datensätze aus einer, sondern die Datensätze von einem Jahr und eben von 6 Tabellen und dies bezüglich hatte ich Dir schon gesagt schau Dir bitte im SQL Syntax das "JOIN" an. Ich habe bisher viel gelernt. Schonmal zwischendurch vielen Dank für deine Hilfe Kein Prob, dafür ist ein Forum da HTH Phil Bearbeitet 8. August 2008 von flashpixx Zitieren
philipp-schoene Geschrieben 27. August 2008 Autor Geschrieben 27. August 2008 So, mein Urlaub ist nun vorbei. Nun habe ich mit dem Chef gesprochen. Ich soll nicht mit ODBC aus Sage KHK zugreifen. Wie er nochmal wiederholte ist ihm die Buchhaltung heilig. Das muss so hinnehmen. Er stellt sich das so vor: Aus Sage KHK wird eine Access Dabenbank exportiert. Diese wird dann in das Prokekt importiert und ergänzt Daten. Er will auch die Kontentabelle abgleichen. Aber nur ein hinzufügen neuer Kote soll möglich sein. kein löschen oder umbenennen. Da dies alles durcheinanderbringt. Wie ich finde ist das keine gute Lösung. Aber ich muss mich dem wohl fügen. Ich bitte euch, auch wenn das nciht so "fachgerecht" ist, mir keine Vorwürfe zu machen. Nun sehe ich also da, wo ich vor 4-5 Wochen auch stand. Ich muss also wieder Daten importieren. Wie schon gesagt habe ich drei Mandanten mit je zwei Tabellen Konten und Werten. Was würdet ihr mir emfehlen: Daraus eine Tabelle zu machen und dazu eine Mandantenspalte einzufügen. Oder die Konten dreigeteilt lassen? Weklches Steuerelement soltle ich nutzen, wenn ich in einem Formular erstmal alle Datensätze eine Mandaten anzeigen lassen möchte? Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.