10
Wie die Funktion Autowert beim import von Access nach SQL Server 2008 erhalten?
Hallo,
ich hab hier ne kleine Datenbank (Access 2010) die ich gerne im Netzwerk mit Berechtigungen nutzen möchten.
Dazu importiere ich die Daten in einen SQL 2008 Server mittels Daten importieren und exportieren und greife mittels ODBC aus der Datenbank darauf zu.
Funktioniert auch, aber die Eigenschaft "Autowert" ist bei den id-Spalten weg.
Wenn ich diese Funktion nun mit dem SQL Server Management Studio aktivieren will, erzählt er mir, dass dies nicht möglich sei, da es schon Daten gibt.
Die Daten löschen und neu eingeben ist aufgrund der Verknüpfungen aber sehr aufwendig.
Auch wenn ich den Startwert deutlich höher als aktuell verwendet wähle.
Außerdem ist das natürlich nervig bei ca. 40 Tabellen das einzutragen.
Wie kann man das überhaupt oder besser machen?
Danke
Stefan
ich hab hier ne kleine Datenbank (Access 2010) die ich gerne im Netzwerk mit Berechtigungen nutzen möchten.
Dazu importiere ich die Daten in einen SQL 2008 Server mittels Daten importieren und exportieren und greife mittels ODBC aus der Datenbank darauf zu.
Funktioniert auch, aber die Eigenschaft "Autowert" ist bei den id-Spalten weg.
Wenn ich diese Funktion nun mit dem SQL Server Management Studio aktivieren will, erzählt er mir, dass dies nicht möglich sei, da es schon Daten gibt.
Die Daten löschen und neu eingeben ist aufgrund der Verknüpfungen aber sehr aufwendig.
Auch wenn ich den Startwert deutlich höher als aktuell verwendet wähle.
Außerdem ist das natürlich nervig bei ca. 40 Tabellen das einzutragen.
Wie kann man das überhaupt oder besser machen?
Danke
Stefan
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 159719
Url: https://administrator.de/forum/wie-die-funktion-autowert-beim-import-von-access-nach-sql-server-2008-erhalten-159719.html
Ausgedruckt am: 03.04.2025 um 16:04 Uhr
10 Kommentare
Neuester Kommentar
Moin Moin,
2. wenn du das nicht willst, dann erstelle die Tabellen im SQL-Server und füge die Daten per Anfügeabfrage (ohne das ID-Feld) an.
Irgendwie kann ich deinen Ausführungen nicht folgen, warum du das so kompliziert gestaltest.
Grüße aus Rostock
Wolfgang
(Netwolf)
ich hab hier ne kleine Datenbank (Access 2010) die ich gerne im Netzwerk mit Berechtigungen nutzen möchten.
definiere: "Berechtigungen"Dazu importiere ich die Daten in einen SQL 2008 Server mittels Daten importieren und exportieren und greife mittels ODBC aus der
Datenbank darauf zu.
sehr umständlichDatenbank darauf zu.
Funktioniert auch, aber die Eigenschaft "Autowert" ist bei den id-Spalten weg.
logisch, was hast du erwartet?Wenn ich diese Funktion nun mit dem SQL Server Management Studio aktivieren will, erzählt er mir, dass dies nicht
möglich sei, da es schon Daten gibt.
jomöglich sei, da es schon Daten gibt.
Die Daten löschen und neu eingeben ist aufgrund der Verknüpfungen aber sehr aufwendig.
das verstehe ich nicht, definiere: VerknüpfungenAußerdem ist das natürlich nervig bei ca. 40 Tabellen das einzutragen.
was ist dann eine große Datenbank bei dir?Wie kann man das überhaupt oder besser machen?
1. normaler Weise erstellt man ein Front- und ein Backend in Access. Das Backend beinhaltet die Tabellen, das Frontend den Rest.2. wenn du das nicht willst, dann erstelle die Tabellen im SQL-Server und füge die Daten per Anfügeabfrage (ohne das ID-Feld) an.
Irgendwie kann ich deinen Ausführungen nicht folgen, warum du das so kompliziert gestaltest.
Grüße aus Rostock
Wolfgang
(Netwolf)
Hallo Wolfgang,
ich habe hier eine bestehende Datenbank mit ca. 40 Tabellen und ca. 1000 Datensätzen in diesen Tabellen.
Ich möchte nun erreichen, dass Jemand in der Tabelle Kunden nicht alle Einträge sieht.
Also ändere ich die Berechtigung auf dem SQL Server so, dass der Benutzer keinen Zugriff auf diese Tabelle mehr hat und erstelle eine Sicht mit entsprechendem Filter.
Das klappt auch.
Es gibt weitere Tabellen wie z.B. Rechnungen, Kundendaten, Konfigurationsdaten, etc die auf die ID der Kundentabelle zugreifen.
Wenn ich diese neu erstelle und eingeb oder importiere erhalten diese ja nun neue IDs und damit stimmen die Links nicht mehr.
Stefan
ich habe hier eine bestehende Datenbank mit ca. 40 Tabellen und ca. 1000 Datensätzen in diesen Tabellen.
Ich möchte nun erreichen, dass Jemand in der Tabelle Kunden nicht alle Einträge sieht.
Also ändere ich die Berechtigung auf dem SQL Server so, dass der Benutzer keinen Zugriff auf diese Tabelle mehr hat und erstelle eine Sicht mit entsprechendem Filter.
Das klappt auch.
Es gibt weitere Tabellen wie z.B. Rechnungen, Kundendaten, Konfigurationsdaten, etc die auf die ID der Kundentabelle zugreifen.
Wenn ich diese neu erstelle und eingeb oder importiere erhalten diese ja nun neue IDs und damit stimmen die Links nicht mehr.
Stefan
Moin StefanKittel,
das, was du vermutlich als Plan bezeichnest, leuchtet mir auch nicht ganz ein.
Hauptnachfrage:
Willst du jetzt diese Datenbank "importieren" oder "migrieren", d.h. ab erfolgreichem Ankommen auf dem SQLServer 2008 ausschliesslich dort arbeiten und den Access-Krams stilllegen?
Oder soll etwa das SQLServer-seitige nur zur Anzeige der in Access erfassten Daten dienen?
Grüße
Biber
das, was du vermutlich als Plan bezeichnest, leuchtet mir auch nicht ganz ein.
Hauptnachfrage:
Willst du jetzt diese Datenbank "importieren" oder "migrieren", d.h. ab erfolgreichem Ankommen auf dem SQLServer 2008 ausschliesslich dort arbeiten und den Access-Krams stilllegen?
Oder soll etwa das SQLServer-seitige nur zur Anzeige der in Access erfassten Daten dienen?
Grüße
Biber
Hallo Biber,
die Daten wandern aus Access in den SQL Server.
Die MDB dient dann als Frontend und die Daten sind nur im SQL-Server.
Stefan
die Daten wandern aus Access in den SQL Server.
Die MDB dient dann als Frontend und die Daten sind nur im SQL-Server.
Stefan
Moin StefanKittel,
na ja, warum willst du dann das AutoWert-Feld weiterhin als Autowert-Feld erhalten - lass es doch als normales Integer-Feld mitlaufen.
Die ganzen PK- und Foreignkey-Constraints passen doch dann weiterhin und die einzige Stelle im Frontend, an der du etwas ändern musst,
ist das INSERTen eines neuen Datensatzes in der heutigen Mit-Autowert-Tabelle...
...da kannst du einen Dreizeiler zur "Berechnung" einer neuen "höchsten" Id einbauen. So what?
Grüße
Biber
na ja, warum willst du dann das AutoWert-Feld weiterhin als Autowert-Feld erhalten - lass es doch als normales Integer-Feld mitlaufen.
Die ganzen PK- und Foreignkey-Constraints passen doch dann weiterhin und die einzige Stelle im Frontend, an der du etwas ändern musst,
ist das INSERTen eines neuen Datensatzes in der heutigen Mit-Autowert-Tabelle...
...da kannst du einen Dreizeiler zur "Berechnung" einer neuen "höchsten" Id einbauen. So what?
Grüße
Biber
Hallo Biber,
stimmt schon, daran habe ich gar nicht gedacht.
Aber die meisten Datensätze werden einfach in der Tabellenansicht hinzugefügt. Ich müßte dann also "überall" Hinzufügenbuttons erstellen.
Gibts vieleicht eine einfachere Lösung?
Zugriff auf bestimmte Datensätze verhindern
Stefan
stimmt schon, daran habe ich gar nicht gedacht.
Aber die meisten Datensätze werden einfach in der Tabellenansicht hinzugefügt. Ich müßte dann also "überall" Hinzufügenbuttons erstellen.
Gibts vieleicht eine einfachere Lösung?
Zugriff auf bestimmte Datensätze verhindern
Stefan
Moin StefanKittel,
versteh ich nicht.
Wo musst du denn "überall" Hinzufügebuttons hinzufügen??
Wer soll denn da neue Datensätze anlegen dürfen in der Kundentabelle??
Und passiert das denn heute absolut ohne Benutzer-/Formularführung "direkt auf der Tabellenansicht"???
Und wenn ja, was wäre daran erhaltenswert?
Hast du denn konkrete Vorstellungen, wie dein Berechtigungskonzept aussehen soll (auf Ebene der Geschäftsprozesse zumindest)?
Die Angaben in deinem Parallelbeitrag kömmen mir eher unverbindlich und abstrakt vor (so wie die FDP-Blase " ein einfaches, gerechtes und faires Steuersystem").
Grüße
Biber
versteh ich nicht.
Wo musst du denn "überall" Hinzufügebuttons hinzufügen??
Wer soll denn da neue Datensätze anlegen dürfen in der Kundentabelle??
Und passiert das denn heute absolut ohne Benutzer-/Formularführung "direkt auf der Tabellenansicht"???
Und wenn ja, was wäre daran erhaltenswert?
Hast du denn konkrete Vorstellungen, wie dein Berechtigungskonzept aussehen soll (auf Ebene der Geschäftsprozesse zumindest)?
Die Angaben in deinem Parallelbeitrag kömmen mir eher unverbindlich und abstrakt vor (so wie die FDP-Blase " ein einfaches, gerechtes und faires Steuersystem").
Grüße
Biber
Es ist eine ganz einfache Datenbank.
Fast nur Formulare mit Unterformularen mit Beziehungen.
Da hat Jemand (nicht ich) einfach ein paar Tabellen angelegt und mittels Formularen und Beziehungen verlinkt.
Fertig.
Aber es funktioniert gut.
Es wird mittels Terminalserver darauf zugegriffen. Eine MDB und fertig.
Nun sollen aber nicht alle Benutzer alle Kunden mehr sehen dürfen und das ist das Problem.
Tabelle Kunden
Untertabelle Kunden_Emailadressen
Untertabelle Kunden_Korrespondez
Untertabelle Tabelle Kunden_Rechungen
UnterUntertabelle Tabelle Rechnungspositionen
etc.
Bild: http://www.test.skittel.de/2.jpg
Konnte man nicht mal im Forum Bilder direkt hochladen?
Stefan
Moin Moin,
oder man legt die MDB in einen Ordner, auf den nur die Berechtigten Personen Zugriff haben.
Grüße aus Rostock
Wolfgang
(Netwolf)
Es ist eine ganz einfache Datenbank.
Fast nur Formulare mit Unterformularen mit Beziehungen.
bei 40 Tabellen würde ich mal vermuten, dass es keine einfache Datenbank ist.Fast nur Formulare mit Unterformularen mit Beziehungen.
Da hat Jemand (nicht ich) einfach ein paar Tabellen angelegt und mittels Formularen und Beziehungen verlinkt. Fertig.
ok d.h. übersetzt, du hast keine Ahnung von Access und bist jetzt damit beauftragt, das Ganze zu ändern!?Aber es funktioniert gut.
Es wird mittels Terminalserver darauf zugegriffen. Eine MDB und fertig.
wie gesagt: 2 MDBs wären besserEs wird mittels Terminalserver darauf zugegriffen. Eine MDB und fertig.
Nun sollen aber nicht alle Benutzer alle Kunden mehr sehen dürfen und das ist das Problem.
ok, dann erstellt man mal eben eine Zugangsberechtigung für die Tabellen und gut is, VBA kannst du doch?oder man legt die MDB in einen Ordner, auf den nur die Berechtigten Personen Zugriff haben.
Tabelle Kunden
Untertabelle Kunden_Emailadressen
Untertabelle Kunden_Korrespondez
Untertabelle Tabelle Kunden_Rechungen
UnterUntertabelle Tabelle Rechnungspositionen
das sieht aus wie ein Faktura-Programm?Untertabelle Kunden_Emailadressen
Untertabelle Kunden_Korrespondez
Untertabelle Tabelle Kunden_Rechungen
UnterUntertabelle Tabelle Rechnungspositionen
Konnte man nicht mal im Forum Bilder direkt hochladen?
jaGrüße aus Rostock
Wolfgang
(Netwolf)
Moin StefanKittel,
ergänzend zu NetWolf:
Wenn der Zustand heute ist, es gibt nur eine MDB-Daten-und-Formulardatei und jeder user hat entweder gar keinen oder unbeschränkten Zugriff darauf....
... diese Ganz-oder-garnicht-Klamotte kannst du nicht einfach auf ein Datenbankblech hochschieben und dadurch automatisch datensatzweise Berechtigungen generieren.
Du musst doch irgendeinen Plan haben, ob es userbezogene/gruupen-/abteilungsbezogene Rechteabstufungen geben soll, ob einzelne Formulare sichtbar/unsichtbar sein sollen, ob nur Kunden aus dem Landkreis Soltau-Fallingbostel für alle bearbeitbar sein sollen oder was-auch-immer.
Grüße
Biber
ergänzend zu NetWolf:
Nun sollen aber nicht alle Benutzer alle Kunden mehr sehen dürfen und das ist das Problem.
Das ist noch nicht ganz das, was ich als ausformuliertes Berechtigungskonzept bezeichnen würde.Wenn der Zustand heute ist, es gibt nur eine MDB-Daten-und-Formulardatei und jeder user hat entweder gar keinen oder unbeschränkten Zugriff darauf....
... diese Ganz-oder-garnicht-Klamotte kannst du nicht einfach auf ein Datenbankblech hochschieben und dadurch automatisch datensatzweise Berechtigungen generieren.
Du musst doch irgendeinen Plan haben, ob es userbezogene/gruupen-/abteilungsbezogene Rechteabstufungen geben soll, ob einzelne Formulare sichtbar/unsichtbar sein sollen, ob nur Kunden aus dem Landkreis Soltau-Fallingbostel für alle bearbeitbar sein sollen oder was-auch-immer.
Grüße
Biber
