Office: (Office 2007) Änderungsdatum beim importieren möglich

Hallo Alfred,

als ich vor einiger Zeit mit meiner Datenbank angefangen habe, hatte ich noch weniger Ahnung wie heute. :-l
Ich suchte damals Im internet ein Beipiel mit dem ich folgendes machen konnte.

Ich wollte für mich eine DB bauen, in der ich nicht nur über ein Formular einen DS neu anlgen kann, sondern wollte die Möglichkeit haben, eine Excel hochzuladen (am besten noch menügeführt) und mit dem bestehenden Access Bestand zu "verkutteln" also:

- gleiche DS (gleiche ReplikationsID) abgleichen und Änderungen aus der Excel Tabelle übernehmen.
- Datensätze, die in der Datenbank unbekannt waren (also in der Excel zB keine Replikationsid hatten) neu anzulegen.

Das alles hat der Code ja auch gemacht. Auf diesem Beispiel heraus habe ich angefangen, die Datenbank aufzubauen.
Das Beipiel hat mir halt auch gut gefallen, weil die Daten nicht nur eingelesen wurde, sondern man auch die Möglichkeit hatte die einzulesende Datei vor anzuschauen, das Ziel auszuwählen und zu entscheiden, will ich nur aktualisieren, sollen auch neu dateu, will ich eine KOpie anlegen, ...
Diese 5 OPtionen die da am schluss kommen.
Ausserdem fand ich die FUnktion super , das sich der COde die Parameter (Quelle, Tabellenblatt, Ziel...) eines Imports gemerkt hat und man bei einem weiterem Import nur diesen Eintrag auswählen musste.


Was dann vor kurzem dazu kam, ich wollte sehen, wann ein DS angelegt wurde und wann er aktualisiert wurde.

Das mit dem Zeitstempel bei Neu und Änderung über das Formular hatte ich ja hinbekommen.
Auch wann bei einem Import ein DS Neu angelegt wurde hatte ich hinbekommen.
Nur das Änderungsdatum beim Import geht nicht. Wo wir jetzt stehen.


Wie ich schon geschrieben habe, kann ich mit meinem Wissen so ein Projekt nicht neu Starten. Musste mich ja auch mit so einer "Krücke" behelfen.
Darum ist das Projekt für mich eher kein Option mehr.

Hat auch nichts mit Motivation zu tun, die hätte ich, eher mit Einsicht :-)

 

Und warum setzt Du das nicht in der Excel-Datei? Das ließe sich doch mit einem klitzekleinen Makro erledigen.

 

... na das war knapp, wollte schon den Thread canceln *Smilie

Aber, gut so. Zum einen musst ja nicht deine Access-Welt in einem Tag erschaffen,
selbst Gott hat 7 Tage für seine gebraucht! *wink.gif*

Ich weiß, wenn man eine DB hat die funktioniert, will man sich nicht gerne davon trennen.
Wird dir aber über kurz oder lang nichts übrig bleiben und besser (Schrecken mit Ende, als Schrecken ohne Ende)

Auch wenn du es mit einer Krücke zuwege bringst... das wird dir irgend wann mal auf den Kopf fallen.
Eine DB verändert sich, du willst... so wie jetzt etwas dazu gestalten.
Das wird aber wie jetzt etwas schwierig werden und du erstellst Krücke um Krücke...
Mach was eigenes, bei dem du dich auskennst mM. Ist auch nicht so schwer wie du es dir vorstellst.
Einen Code zu verwenden in dem du dich nicht mal im kleinsten Detail auskennst, oder du hast dir einen selbst erarbeitet
bei dem du dich 100% auskennst...
was ist besser?

Hast zumindest mal die SQL die ich eingestellt habe getestet? Sie funktioniert und das wäre mal ein Anfang.

 

Hi,

da ich ja nun die Prozedur (MID_ExTxFeld) identifiziert habe, in der die Daten übernommen werden, könnte man dort natürlich auch ansetzen und die Prüfung vornehmen und ein Flag setzen bei geänderten Werten und davon abhängig vor dem Update das Änderungsdatum setzen.

Leere Felder werden dort übrigens ignoriert. Fragt sich also wie es gehen könnte, wenn ein Datenfeld tatsächlich gelöscht werden soll... *confused.gif*

 

Ralf,
ich gebe dir ja recht, würde theoretisch funktionieren. Das Problem dabei ist: die Excel selber ist auch nicht aus einem "Guss" . Das heißt, die Excel ist auch erst mal eine Sammlung von Damensätzen und wird nur gelegentlich eingelesen.
Angenommen, ich würde aus einer anderen Quelle einen DS für meine Excel bekommen, der schon in der Datenbank existiert. Bevor ich die Tabelle einlese, müsste ich doch bei jedem DS überprüfen, ob es Abweichungen zu Datenbank gibt und bei bedarf ein neues Datum setzen (Falls sich was geändert hat)
Würde ich das Änderungsdatum standardmäßig bei jedem Import bei jedem DS setzten, egal, ob sich tatsächlich was geändert hat, oder nicht, dann sieht es nach dem Import so aus, als ob überall Änderungen vorgenommen würden. Das würde dann nicht der Wahrheit entsprechen.
Anderseits müsste ich jeden Datensatz vor dem Import überprüfen, ob es Änderungen gab.

Ich gebe dir soweit recht, es würde dann funktionieren, wenn ich der alleinige Master der Excelliste und Daten wäre und ich in der Excel Mappe zB im Change Ereignis jeweils das Datum bei einer Änderung anpassen lasse.
Aber wie gesagt, ich bekomme Daten auch von außerhalb und die muss ich dann erst mal prüfen, ob es Änderungen gab.

GRuß Jockel

 

Leere Felder werden dort übrigens ignoriert. Fragt sich also wie es gehen könnte, wenn ein Datenfeld tatsächlich gelöscht werden soll...
__________________
Gruß Maggie



dazu müsste man direkt in der Datenbank auf das Formular, den DS aufrufen und das entspr. Feld löschen.

 

Hi Maggie,

dazu müsste das Feld erstmal gefunden werden. Wie will man das machen? Eine Möglichkeit, ganz knapp vorbei an einer Krücke, wäre den Namen vorzuschreiben. Und wehe, das heißt nicht DS_geändert_am ;-)

 

Hallo Maggie,

wenn die Prozedur (MID_ExTxFeld) dafür zuständig ist, kann man von dort aus nicht die Zelle beschreiben ?

CurrentDb.Execute "UPDATE IMPORT SET DS_Geaendert_Am = now"


Gruß Jockel

 

Hallo miteinander,

ganz recht, so sehe ich das auch, aber angesichts der gegebenen Voraussetzungen würde ich das in Kauf nehmen.
Das ist dann natürlich keine Code-Anpassung, die zur Veröffentlichung an die Allgemeinheit geeignet wäre.

Eher nicht. Das ist ja alles sehr "modular" programmiert, d.h. hier werden zahllose Prozeduren für ganz spezifische
Detail-Aktionen eingesetzt. Darum ist das ja auch so schwer durchschaubar.

Ich würde daher tatsächlich meinem Vorschlag folgen - wer einen besseren hat, sollte sich natürlich gern melden -
und in besagter Prozedur die Prüfung hinzufügen, um das Update-Flag zu setzen, das dann wiederum an anderer
Stelle ausgewertet wird.

PS:
Meine Erkenntnisse und Vorschläge beziehen sich natürlich nur auf den hier geschilderten Fall des Updates.
Wie sich das auf die anderen Verarbeitungs-Optionen auswirken könnte, habe ich noch nicht untersucht.

 

Hallo,

zum letzten Mal, habe nicht so die Lust an eine Wand zu schreiben ohne Echo.

Nur, das eine noch, eventuell testest ja das... ist aber vermutlich nicht sicher *Smilie...

Füge einen Ordner "C:\Test\" ein und in diese die Datei Import.xlsx
Weiter geht es mit meiner Beispiel-DB...

1.) Abfrage tmpExcel kontrollieren ob sie Daten zeigt
2.) wenn nicht, SQL wie schon in #43 gezeigt korrigieren und ggf wieder kontrollieren
3.) qryInsertInto ausführen
4.) Tabelle tblImport kontrollieren, Daten sind vorhanden?
5.) Daten in tmpExcel ändern (ist in Access möglich, Abfrage tmpExcel aufrufen und Daten ändern)
6.) qryUpDate ausführen
7.) Tabelle kontrollieren
8.) wenn Änderung durchgeführt wurde gut, wenn nicht, schlecht... aber nicht meine Schuld *g*

Und auf eine solche Weise kann man alles gut regeln und auch das Änderungsdatum einfügen, wenn man möchte.
Ist Übersichtlich und hat nicht 1KM Code hinter sich!

Diese Abfrage tmpExcel und qryInsertInto lassen sich wunderbar mit VBA zusammenstellen und sind dann individuell änderbar.

Einen schönen Abend wünsche ich noch!

 

Hallo Alfred,

deine Beispiel-DB kann nicht getestet werden weil Tabellen fehlen.

Davon abgesehen sind die Anforderungen an die Import-Funktionalität
hier offensichtlich differenzierter. Aber das kannst du ja nicht wissen,
weil du bekannter-maßen nicht alle Beiträge eines Threads liest. *wink.gif*

 

... wenn du meine BDB nicht verstehst, kann ich nichts dazu sagen.
Da solltest eben genauer nachschlagen, genauer hinsehen, genauer überlegen...
und das Thema Aktualisieren ev. aufgreifen...
Nach dieser Ansage...

.
weiß ich nicht, ob du meine BDB überhaupt verstehst.
Es ist eine Option zum Nachdenken für den TS gewesen. Alles ist erweiterbar...
Du hast doch nicht gedacht, dass es schon ein fertiges Gegenstück zu seiner DB war...
Alles was mit Abfragen machbar ist, ist ein Gewinn für eine DB...
und damit belasse ich es einfach mal.

...und ich bitte weiters, solche Anspielungen in Zukunft zu unterlassen,
es gehen dich relativ wenig an, ob ich etwas durchlese oder nicht, danke.

Einmal gestern, einmal heute, irgend wann sollte es doch reichen, oder Kindergarten? *grins

 

Hallo Alfred,

danke für das Beispiel. Verstehe ich das Beispiel richtig: ? Neue Datensätze werden beim Importieren der Excel nur angelegt, wenn in der Spalte ID bereits ein Eintrag ist, oder mach ich was falsch.

Momentan ist es so, nur wenn sich bei einem DS in der Excel in der Spalte ID ein Eintrag befindet, wird je nachdem neu angelegt bzw upgedatet.

Stimmt das so ?

Danke
Jockel

 

Hallo Jockel,

...das Ist nur ein unfertiges Beispiel...
ich wollte dir nur zeigen, wie du das auch einfach über
einer oder mehreren Abfragen, realisieren kannst!

Das Anfügen, wenn es keine ID gibt aber schon Daten vorhanden sind,
habe ich nicht mit eingefügt, ich wusste ja nicht ob du überhaupt darauf reagierst!
Werde mir nicht unnötig Arbeit machen.

Aber, wenn es dich wirklich interessiert, kann ich dir dabei weiterhelfen...
Am Nachmittag aber erst.

 

Hallo Alfred,
klar interessiert es mich.
Gerne würde ich wieder mit einer Replikations-ID arbeiten.
Also alle DS die in der Excel keine ID haben, bekommen dann beim importieren die ID (über Autowert)

Mit diesem Beispiel wäre mir echt geholfen. Ich denke, dann bekomme ich das auch mit dem Änderungsdatum hin.

Schönes WE

Jockel