Office: (Office 2013) mit VBA in neuer Tabelle Tabellenfeld als AutoWert-Typ Replikations-ID erstellen

Hallo Erfahrungsträger,
ich bemühe mich schon wieder viel zu lange, in einer mit VBA neu erstellten Tabelle ein Tabellenfeld als AutoWert mit Replikations-ID anzulegen. Und zwar ohne irgendwelche Tricks, etwa mit einer Funktion als DefaultValue.
Ich möchte einfach nach der Erstellung der Tabelle mit VBA hinterher dasselbe im Tabellen-Entwurfsmodus sehen, wie wenn ich das von Beginn an manuell im Entwurfsmodus gemacht hätte, also bspw.

TestGUID AutoWert

Feldgröße Replikations-ID
Indiziert Ja (ohne Duplikate)

Aber ich bekomme es nicht hin. Im besten Falle sieht es so aus:

TestGUID Zahl

Feldgröße Replikations-ID
Eingabe erforderlich Ja
Indiziert Ja (ohne Duplikate)

und das unabhängig davon, ob ich es mit SQL versuche

ALTER TABLE Test ALTER COLUMN TestGUID GUID;

(ALTER TABLE Test ALTER COLUMN TestGUID UNIQUEIDENTIFIER; bringt leider immer einen Fehler so dass dies in Access offensichtlich nicht funktioniert.)

oder direkt mit DAO

DBCU.TableDefs("Test").Fields("TestGUID").Attributes=dbAutoIncrField

was leider nicht erlaubt ist, egal, welchen Wert ich zuweisen will.

Auch die Definition zunächst als Autowert-Feld vom Typ LONG INTEGER und die danach folgende Umwandlung in eine Replikations-ID funktioniert nicht.

Ich mag auch keine Funktion als DefaultValue eintragen, da dies nicht unmittelbar dokumentierbar, d.h. im Entwurfsmodus sichtbar, ist.
Hier und auch im Internet habe ich nach langen Suchen nichts gefunden.

Bitte lasst mich an Euren positiven Erfahrungen teilhaben.

:)

 

Hi,

zeige doch bitte auch gleich den VBA-Code - bitte in Code-Tags verpackt! - dazu, der das Ergebnis liefert.

 

Wie Sie ADOX AutoWert Feldgröße für Replikations-ID erstellen

 

Hallo,

...ob meine Antwort positiv ist, darfst selber entscheiden.

Also, eine Replikations-ID wird in AC 2016 nicht mehr angeboten (da sollten aber schon die Alarmglocken läuten)

2013 und kleiner weiß ich nicht mehr, benutze diese Möglichkeit einfach nicht, da mir zu mühsam.
Denke aber, es wird auch in AC13 nicht mehr angeboten.
Da es schon andere Möglichkeiten dafür gibt.

Habe mal eine Replikations-DB für einen Freund erstellt
und das wieder zurücksetzen müssen... war eine mühsame Sache.
Aber, hat funktioniert, es waren alle Daten wieder passend und vollständig.
Ich mach das jedenfalls nie mehr wieder.

Eventuell, habe ich es auch falsch verstanden und es geht um ganz etwas anderes *biggrin.gif*

 

Hi,

(nur der Vollständigkeit halber)
Das heißt evtl. auch, dass der Datentyp (bzw. die "Feldgröße") "Replikations-ID" nicht mehr einsetzbar ist.

Vermutlich der Grund dafür, dass es dir nicht gelungen ist, ein solches Datenfeld anzulegen.
Es scheint sich also wirklich nicht mehr zu lohnen, sich darüber Gedanken zu machen.

Die Vergabe einer eindeutigen ID spezieller Bauart könnte man ja auch im Eingabeformular sicherstellen.

 

\@Alfred,

die Feldgröße Replikations-ID ist nach wie vor für einen Autowert auch unter Access 2016 vorhanden. *rolleyes.gif*

 

\@Nouba

aha danke, das habe ich nicht gewusst und anscheinend nicht nur ich nicht, sondern Maggie auch nicht!

...nur der Vollständigkeit halber! *wink.gif*

Vor nicht langer Zeit wollte ich eine Replikations-DB mit AC16 starten... geht nicht mehr!
War aber eine .mdb!
Ist da ein Unterschied - Replikations-DB und Replikations-ID
Ich weiß es nicht, wäre für mich gut zu wissen, denn ich würde es benötigen!
Für jemand anderen, nicht für mich.

 

\@Alfred:
Ich hatte den Beitrag nachträglich editiert, weil ich bemerkt hatte, dass der Kommentar an die falsche Stelle gerückt war.
Das war, wie man sehen kann, zum Zeitpunkt deines Zitats eigentlich schon gespeichert.

Dass es diese "Feldgröße" trotz fehlender Unterstützung der Replikation noch gibt, wundert mich.
Hat dann aber wohl nur den Grund, dass derartige Tabellen weiterverwendet werden können - oder wie seht ihr das?

 

\@Maggie

...ich kann das nicht beurteilen, da es bei mir nicht mehr funktioniert und ich es
weder nachvollziehen kann, noch es unbedingt nachvollziehen möchte.

Es wird mir diese alte Replikations-DB auch nicht mehr wie gewohnt mit diesem runden, gelben Zeichen angezeigt.

Außer das ich einen Freund helfen wollte, was nicht unbedingt sein muss, verbindet mich mit einer Replikations-ID/DB nichts mehr.

PS: Code:

Also, ich kann diese DB nicht mehr öffnen!
Eben noch mal getestet... das ich hier keinen Unsinn verbreite...

 

Auweia. Da habe ich ja etwas losgetreten...
Der Hinweis von Eberhard scheint mir der kompetenteste zu sein und weiter zu helfen. Ich werde mich gleich morgen früh an die Umsetzung machen. Es klingt gut und gibt mir wieder Hoffnung.
Andere werfen Replikations-ID und Datenbank-Replikation in die selbe Kiste, ... wenn ich das richtig verstanden habe ... is aber janz wat anderes ... Muss ich den Unterschied noch erklären?

 

Ich hatte es schon schreiben wollen, dann aber wieder verworfen...

Ich denke, es macht schon einen Unterschied, ob es sich tatsächlich um eine replizierte DB (bzw. ein Replikat) handelt, oder ob lediglich der Datentyp Autowert mit der Feldgröße Replikations-ID in einer Tabelle verwendet wurde.

Soll heißen: Du stehst mit dieser Interpretation nicht allein. *Smilie

 

Für jene, die ihr Denlken mit Fakten anreichern wollen: Eine Replikations-ID ist nichts anderes als eine Umsetzung einer GUID.

Die Verwendung einer GUID ist zwar beim Synchronisieren/Replizieren hilfreich, weil praktisch keine gleiche GUID zweimal erzeugt werden kann und es so keine ID-Überschneidung bei Datenzusammenlegungen geben kann - aber es gibt weitere Anwendungen.

 

Hallo Eberhard,
ich brauche etwas länger, da ich bisher nicht auf ADO umgestiegen bin und auch nicht umsteigen wollte, sondern bei DAO verblieben war. Und da ist eine 1:1-Umsetzung so nicht möglich. Ich bin also am Versuchen, das ohne ADO und in DAO zu erledigen... ...werde dann aber vermutlich bei meinen alten Problemen bleiben und nicht zum Erfolg kommen. Aber ich tue mich aus den verschiedensten Gründen schwer mit einer ADO-Umstellung.
Vielleicht hast Du noch einen SQL-Tipp?

Übrigens Gruß an die Zitzenfichte, ... falss sie noch steht...

 

Ein Umstieg auf ADO wird nun nicht nötig sein, aber Methoden, die es nur da gibt und die dann und wann nützlich sind (Disconnected Recordsets, Methode GetString u.a.) kann man doch nutzen.

Hier ein Link, wo Methoden von DDL, DAO und ADO(X) nebeneinandergestellt werden: Strukturänderungen an der Datenbank

Dass das Vorhaben in Jet-SQL durchführbar ist, glaube ich eher nicht.

Über die Suchworte "sql ddl dao guid" findest Du einige Stellen, die Du intensiver recherchieren könntest, u.a. Field type reference - names and values for DDL, DAO, and ADOX und da eine DAO-Konstante für GUID (=> dbGUID).

Zitzenfichte: Oha, ein Reinsberg-Insider.
Ja, das Jahrhunderthochwasser August 2002 hat sie überstanden, und so viel ich weiß, will sie noch ein paar Jährchen auf die 200 darauflegen.

 

Hallo Allerseits,
ich bin nun aus dem Urlaub zurück. Leider hat sich nichts geändert.
Mit DAO habe ich nichts gefunden und es scheint wohl auch wirklich nicht zu funktionieren.
Mit ADO scheint es sicher zu funktionieren. Allerdings wäre mein Aufwand unvertretbar hoch, nur diese Funktion in ADO zu realisieren.
Ich müsste weit in die bestehenden Routinen eingreifen. Da die entsprechende Tabelle gerade erst sukzessive durch DAO im Entstehen ist, kann ich nicht mittendrin mit ADO drauf zugreifen.
Die einzige Möglichkeit, zum Ergebnis zu kommen, sehe ich darin, die bereits in DAO erstellte Tabelle mit ADO anschließend nochmals zu öffnen und die Autokorrektur-Eigenschaft nachträglich einzustellen, obwohl mir auch dafür der Aufwand recht hoch erscheint. Abgesehen davon fehlt mir die Erfahrung, mit ADO eine bestehende Tabelle für Eigenschaftsänderungen zu öffnen. Ich schaffe es nicht, die Tabelle zu öffnen und für das betreffende Feld die Autokorrektur-Eigenschaft einzustellen. Alle Beispiele, die ich im Internet gefunden habe, behandeln lediglich das Erstellen einer neuen Tabelle mit den gewünschten Eigenschaften und nicht das Ändern der gewünschten Eigenschaft in einer bereits bestehenden Tabelle.
Nur dazu müsste ich, wie oben angemerkt, zu tief in die Struktur der Routinen eingreifen. Ich müsste dazu zunächst feststellen, ob eine zu erstellende Tabelle ein GUID-Feld als Autokorrekturwert enthält und diese Tabelle dann mit ADO erstellen, während alle anderen weiterhin mit DAO zu erstellen wären, um den Gesamtablauf nicht vollkommen auf ADO umstellen zu müssen.
Wenn mir also nicht jemand an einem Beispiel zeigen kann, wie ich mit ADO in einer bestehenden Tabelle einem GUID-Feld beibringen kann, dass es Autowert sein soll und dies, ohne eine Funktion als Autowert zu verwenden, werde ich wohl die Funktion als "gern gehabt" vergessen müssen.