Access-o-Mania

Hallo,

ich habe Daten in einer SQL-Datenbank. Diese sind in meine Access-DB verknüpft.
Mit der Datenbank arbeiten mehrere Personen. Leider habe ich nur Zugriff auf den SQL Datensatz.
Es ist nicht möglich die Rechte für alle zu ändern und auch wird dieser Datensatz dort benötigt.

Wie kann ich den SQL-Datensatz (mit meiner Berechtigung) per VBA als Tabelle speichern?

danke
gruß Christoph

Hallo,

wenn ich richtig verstehe, willst Du die Daten aus der SQl-Server-Tabelle in einer  neuen lokalen Access-Tabelle speichern.


z. B.:


Select * into DeineAccessTabelle from DeineSQLTabelle

Hallo,

Access-Bordmittel Tabellenerstellungsabfrage geht nicht?

Per VBA gibt es verschiedene Möglichkeiten, diese reichen vom Absetzen eines SQL Statements per CurrentDB.Execute oder DoCmd.RunSQL sowie auslesen per DAO in ein Recordset und überleiten in eine neue Tabelle oder ähnliches per ADO.

Kommt drauf an, wie komplex die Sache ist...

ZitatLeider habe ich nur Zugriff auf den SQL Datensatz.
Es ist nicht möglich die Rechte für alle zu ändern und auch wird dieser Datensatz dort benötigt.

??? ??? ???

verstehe ich leider überhaupt nicht. sorry. Dafür habe ich zu wenig Ahnung.

Hallo,

Zitatverstehe ich leider überhaupt nicht. sorry.

...und ich das auch nicht:

ZitatLeider habe ich nur Zugriff auf den SQL Datensatz.
Es ist nicht möglich die Rechte für alle zu ändern und auch wird dieser Datensatz dort benötigt.

kannst du das mal auf Deutsch übersetzen - ?


Kannst du mit dem Tip von DF6GL nix anfangen?
Select * into DeineNEUEAccessTabelle from DeineSQLTabelle

Peter

Hallo,

habe das schon gelöst und aber meine Erweiterung hier garnicht mitgeteilt.
Soll in eine passwortgeschützte mdb geschrieben werden.

Hier ohne PW:
SELSECT .... INTO ... IN 'Verzeichnis und Datei' FROM ...

Mit Kennwort gehts nicht, auch wenn ich das über die Entwurfansicht mache und die Tabelle verknüpfe. Das Kennwort wird zwar abgefragt und gespeichert, gibt dann aber ein Fehler. Kennwort falsch

Mit Kennwort:
SELSECT .... INTO ... IN 'Verzeichnis und Datei' FROM ... '[;PWD=blabla]

Hi,

siehe hier:
http://www.access-o-mania.de/forum/index.php?topic=12803 (http://www.access-o-mania.de/forum/index.php?topic=12803)

Peter

oh sorry. jetzt wird mir einiges klar. Ich habe im falschen Thread geantwortet.
Ich meinte natürlich, dass ich mit der Hilfe in dem anderen Thread nicht weiterkomme.

Soll ich das im anderen Thread nochmals schreiben :-)
(da sollte das auch hin.

"verstehe ich leider überhaupt nicht. sorry. Dafür habe ich zu wenig Ahnung."

Hi,

ZitatSoll ich das im anderen Thread nochmals schreiben

nein, lass es jetzt hier weiterlaufen, setze aber den anderen Thread in deinem Startbeitrag auf 'gelöst'

Ich muss ehrlich gestehen, dass ich noch NIE ein Kennwort für eine Datenbankverbindung mit einem SQL-String mitgeschickt habe.
Versuche einfach einmal mittels eines Connectionstrings eine Verbindung zu dieser Datenbank aufzubauen.
Beispiele für verwendbare Connectionstrings findest du in diesem Link http://www.connectionstrings.com/access (http://www.connectionstrings.com/access)

ZitatDas Kennwort wird zwar abgefragt und gespeichert, gibt dann aber ein Fehler. Kennwort falsch

Naja, was erwartest du hier ... ich glaube nicht, dass sich die Datenbank irrt :)

Auf jeden Fall muss es dir erst mal gelingen einen brauchbaren Zugriff auf die Datenbank zu bekommen - alle weitere Mühe ist ohne den Zugriff ohne Wert.

Peter

also wenn ich die mdb ohne Kennwort habe funktioniert das schreiben in die mdb.

in eine kennwortgeschütze aber nicht. Gehe davon aus, dass das Passwort irgendwie falsch mitgegeben wird, bzw. der code nicht korrekt ist. Das Kennwort auf jeden Fall!
Habe auch mal gegooglet und einen Thread mit diesem Problem gefunden; jedoch ohne Antwort.

Wie kann man das in einen connection string umbauen?

SELSECT .... INTO ... IN 'Verzeichnis und Datei' FROM ... '[;PWD=blabla]

Guten Morgen,

sieh bitte mal hier rein - donkarl hat da ein Codebeispiel

www.donkarl.com?FAQ6.19 (http://www.donkarl.com?FAQ6.19)

Grüße
Peter

leider kann ich den code so nicht einbauen, da ich das in einer tabellenerstellungsabfrage benötige und hierzu sql benötigt wird, wie in meinem letzten Beitrag beschrieben ist.

Na aber hallo,

funktioniert wenigstens der fehlerfreie Zugriff auf die Art wie donkarl vorschlägt?

Zitatleider kann ich den code so nicht einbauen, da ich das in einer tabellenerstellungsabfrage ....

Wenn JA, was sollte dich daran hindern es dennoch so zu tun wie donkarl vorschlägt ??? ??? ???

'Datenbank mit Kennwort öffnen
Set db = acc.DBEngine.OpenDatabase(strDb, False, False, strPWD)

...und dann im Anschluß dein INSERT INTO via....

db.Execute "SELECT INTO  ....  "

Dein ganzes Problem scheint am Zugriff zu scheitern....?

HTH

Peter

ich weiß nicht wie ich das zusammenbauen muss.

Hier mal mein Versuch (geht aber nicht)

strDb = "\\..."
strPWD = "test"
Set db = acc.DBEngine.OpenDatabase(strDb, False, False, strPWD)

db.Execute SELECT dbo_PMM_PROT.PMID, dbo_PMM_PROT.FIRMENNR, dbo_PMM_PROT.ZIFFER, dbo_PMM_PROT.KLASSE, dbo_PMM_PROT.BEZEICHN, dbo_PMM_PROT.KDIENST, dbo_PMM_PROT.KDATUM, dbo_PMM_PROT.BELEGART, dbo_PMM_PROT.ADATUM, dbo_PMM_PROT.GUID, dbo_PMM_PROT.ARCUSER, dbo_PMM_PROT.DFORMAT INTO PMM_PROTOKOLL FROM dbo_PMM_PROT;

Hallo,

ZitatstrDb = "\\..."

mal langsam jetzt ... ist das ein SQL-Sever oder eine Access-Datenbank?

...und wenn ja welche Version bitte?

ich muss auf ein fileserver kommen und dort liegt eine mdb mit passwortschutz
x:\.. kann ich nicht angeben, da nicht sichergestellt ist, dass die Laufwerke immer gleich angebunden sind.

Hi,

naja, dann denke ich, dass auf dem Fileserver eine Freigabe exisiteren sollte, in der deine DB abgelegt ist.
Die entsprechenden Zugriffsrechte (Freigabe und NTFS-Berechtigungen) vorausgesetzt sollte die DB schon errecihbar sein.

Per UNC-Pfad  mit \\Servername\Freigabename\Datenbank.mdb

Zitatx:\.. kann ich nicht angeben, da nicht sichergestellt ist, dass die Laufwerke immer gleich angebunden sind

WHY???

Werden die Netzlaufwerke denn nicht per Anmeldescript eingebunden? (net use X: \\Servername\Freigabename /persistent:yes)

hi, die db ist ja erreichbar, aber wenn ich db mit kennwort versehe, dann komme ich nicht mit meiner bisherigen Lösung drauf.
Also es würde funktionieren, wenn die mdb nicht kennwortgeschützt ist.

macht es einen Unterschied, ob ich

g:\...

oder

\\...

im code verwende?

Mein Problem ist, dass ich den sql-code nicht hinbekomme, dass er das kennwort korrekt übergibt.

geht das nicht?

und kann ich im SQL-Code den Pfad/Dateiname auch zuammensetzen, wie in VBA?

verz = DFirst("Verzeichnis", "werk")
verz = verz & "\Datensätze\pmdb_dokumente.mdb"

so funktioniert es nicht:

SELECT dbo_PMM_PROT.PMID, dbo_PMM_PROT.FIRMENNR, dbo_PMM_PROT.ZIFFER, dbo_PMM_PROT.KLASSE, dbo_PMM_PROT.BEZEICHN, dbo_PMM_PROT.KDIENST, dbo_PMM_PROT.KDATUM, dbo_PMM_PROT.BELEGART, dbo_PMM_PROT.ADATUM, dbo_PMM_PROT.GUID, dbo_PMM_PROT.ARCUSER, dbo_PMM_PROT.DFORMAT INTO PMM_PROTOKOLL IN verz
FROM dbo_PMM_PROT;


gruß
chris

ich bitte noch im Hilfe für das Problem mit der Kennwortübergabe und die Verzeichnisangabe.

Herzlichen Dank

Guten Morgen,

Zitatso funktioniert es nicht

Das will ich dir gerne glauben!

Zitatund kann ich im SQL-Code den Pfad/Dateiname auch zuammensetzen, wie in VBA?

NEIN

Das was du da schreibst ist kein SQL-Befehl, der funktionieren kann.
Die Syntax des SELECT ... INTO ist falsch, da fehlt ausserdem der Name der Zieltabelle in deiner DB.

Bitte schau dazu hier mal rein http://www.w3schools.com/Sql/sql_select_into.asp (http://www.w3schools.com/Sql/sql_select_into.asp)

Dann fällt mir auf, dass deine Quell-Tabelle mit dem Präfix dbo benannt ist - ist das sicher kein SQL-Server - die Frage habe ich schon einmal gestellt ...

die Zieltabelle fehlt nicht:
... INTO PMM_PROTOKOLL IN ...

dbo_PMM_PROT ist eine verknüpfte SQL-Tabelle in der Datenbank.

Nochmals zum Problem. Es funktioniert ja so alles, außer eben eine Übergabe des Passworts(natürlich nicht mit der Var"verz"), das ich gerne in der Ziel-Mdb einstellen würde.

gruß

Hallo,
also dann versuchen wir's nochmal  ;)

Zitatdie Zieltabelle fehlt nicht:
... INTO PMM_PROTOKOLL IN ...

stimmt - habe ich leider nicht gesehen scheinbar haben mich die Feldnamen verwirrt.

Also da du dich vehement gegen den Beispielcode von donkarl wehrst  ;)  versuch mal meine umgebaute Version einzubinden.
In der Kurzfassung (auskommentiert) klappt das bei mir!


Public Sub DBZugriff()

   Dim db As DAO.Database, strDb As String
   Dim acc As New Access.Application 'weitere Access-Instanz erstellen
   Const strPWD As String = ";pwd=123"
   strDb = "X:\DeinPfad\muster.mdb"
   'bzw.   "\\Servername\Freigabename\Datenbank.mdb"
   'Datenbank mit Kennwort öffnen
   Set db = acc.DBEngine.OpenDatabase(strDb, False, False, strPWD)
   acc.OpenCurrentDatabase strDb
   'db.Execute ("SELECT * INTO Zieltabelle FROM Quelltabelle")
   
   db.Execute ("SELECT dbo_PMM_PROT.PMID, dbo_PMM_PROT.FIRMENNR, dbo_PMM_PROT.ZIFFER, dbo_PMM_PROT.KLASSE, dbo_PMM_PROT.BEZEICHN, " & _
               "dbo_PMM_PROT.KDIENST, dbo_PMM_PROT.KDATUM, dbo_PMM_PROT.BELEGART, dbo_PMM_PROT.ADATUM, dbo_PMM_PROT.GUID, " & _
               "dbo_PMM_PROT.ARCUSER, dbo_PMM_PROT.DFORMAT INTO PMM_PROTOKOLL FROM dbo_PMM_PROT;")


   Set db = Nothing
   Set acc = Nothing
 
End Sub


Dass du dein Kennwort einbauen musst versteht sich von selbst. 8)

Ach ja und ich gehe davon aus, dass sich beide Tabellen in der gleich DB befinden, also in deinem Backend.
Der obige Code soll dann in deinem FE sein.

Untenstehende Codeteile kannst du m.E. auskommentieren da ein sichtbares Öffnen der Datenbank nicht notwendig erscheint.

   Dim acc As New Access.Application 'weitere Access-Instanz erstellen
   acc.OpenCurrentDatabase strDb
    Set acc = Nothing


HTH
Peter

achso jetzt verstehe ich. Benötige also gar keine Abfrage.
Dachte ich benötige für meinen Fall eine Tabellenerstellungsabfrage. Geht das dann genauso mit VBA?
Welche Vorteil oder warum gibt es die Möglichkeit als Abfrage:Tabellenerstellungsabfrage?

Probier es gleich mal aus.

danke
gruß Christoph

Guten Morgen,

ZitatBenötige also gar keine Abfrage

naja, schau, das kommt darauf an von wo aus man das sieht.
Arbeitet man mit 'normalen' Access-Boardmitteln dann kommt diese 'Tabellenerstellungsabfrage' - was für ein Wort - zum Tragen,
in dem man aus einer ganz einfachen Auswahlabfrage im Abfragenentwurf eine solche macht.
Wechselst du danach im Abfragenentwurf auf die SQL-Ansicht hast du meist schon einen brauchbaren SQL-String zur Verfügung, den du dann ....

ZitatBenötige also gar keine Abfrage.
Dachte ich benötige für meinen Fall eine Tabellenerstellungsabfrage. Geht das dann genauso mit VBA?

Das stimmt so nicht ganz ...

Arbeitest du mit VBA, dann kommt hier unter Anderem ein SQL-String zum Tragen, der an geeigneter (richtiger) Stelle eingetragen oft Wunder wirkt :)
Nun ist es so, dass man mit VBA und den darin verwendbaren Datenzugriffsmethoden und Funktionalitäten ja nicht nur Datensätze auslesen und in Recordsets verpacken kann sondern auch über Commandobjekte bei ADO und über die Executemethode bei DAO SQL-Befehle gegen eine Datenbank schicken kann.
Im Beitrag habe ich unter db.Execute eben genau den SQL-String der von dir benötigten Tabellenerstellungsabfrage eingebaut.

Was nun noch zu testen ist, wäre die Angelegenheit mit dem UNC-Pfad ("\\Servername\Freigabename\Datei....")
Die Passwortübergabe funktioniert definitiv, wurde von mir getestet! 8)

Grüße
Peter

muss ich am Dienstag mal austesten und gebe anschließend Rückmeldung.

Hallo,

bei mir erscheint die Meldung: Laufzeitfehler 3078
...findet die Eingangstabelle dbo_PMM_PROT nicht ...

Dabei ist die SQL-Tabelle in der mdb verknüpft und kann ich auch öffnen.
In der Tabellenerstellungsabfrage hats ja auch funktioniert.

Woran kann das liegen?

danke
Christoph

@database
kannst du mir da weiterhelfen?

danke

Hallo,  

Access wird schon recht haben...


Kontrollier nochmal GENAU die Schreibweise und den Namen der Tabelle überall dort, wo sie verwendet wird.


Poste auch mal die gesamte Codezeile, an der der SQL-String eingesetzt ist.

mal ne andere frage.

die Tabelle PMM_PROTOKOLL in die geschrieben werden soll, ist auch in der geöffneten DB verknüpft. Kann ich da nicht direkt schreiben - ohne Kennwort - um dem Thema mal ein Ende zu geben?
Problematik war ursprünglich ja eine andere, dass ich den Code über eine Abfrage hatte. Aber über VBA siehts doch dann wieder anders aus.

gruß christoph

Hallo,


vielleicht meinst Du sowas:

SELECT * FROM MeineTabelle IN '' [MS Access;Database=C:\test\test.mdb;pwd=mypass] Where  irgendwas

Hallo,

Punkt 1
Bitte die Hinweise von DF6GL in Bezug auf den Tabellennamen bachten!
Punkt 2
Wir laufen im Kreis lieber Freund!

Bei der ganzen Geschichte um deine Zugriffsprobleme war immer die Rede davon, dass die gesamte Aktion vom FE aus auf das durch Kennwort geschützte BE erfolgen soll.

ZitatKann ich da nicht direkt schreiben - ohne Kennwort - um dem Thema mal ein Ende zu geben?

Na klar kannst du das!
Allerdings genügt dann prinzipiell eine TABELLENERSTELLUNGSABFRAGE im BE wenn der Vorgang einmalig durchgeführt werden soll.

Hast du vor diese Transaktionen öfters zu machen, dann solltest du mit meinem Code vom FE aus diese durchführen können.
Wenn das Ganze jetzt dann doch wieder ohne Kennwort erfolgen soll, dann ersetzt du in meinem Code die Zeile
Set db = acc.DBEngine.OpenDatabase(strDb, False, False, strPWD)
durch
Set db = acc.DBEngine.OpenDatabase(strDb)
...und verwirfst diese Zeile ganz
Const strPWD As String = ";pwd=123"

Das Datenbankkennwort ist in BEIDEN Fällen VOR Ausführung des Codes bzw. vor Ausführung einer Tabellenerstellungsabfrage zu ENTFERNEN!

danke für die geduld.

Seit Tread-Beginn haben sich die Situtationen immer wieder geändert, da neue Möglichkeiten aufkamen. Konnte es jetzt ohne Kennwort lösen - ich habe es mit Kennwort aber nicht hinbekommen. Bin beim googlen aber auch auf ein gleiches Problem gestoßen - ohne Lösung.

gruß Christoph

Hallo,

freut mich dass es letztendlich erfolgreich läuft.

Die Sache mit dem Kennwort ist mir aber trotzdem nicht geheuer, da es bei mir in der Simulationsumgebung einwandfrei ausführbar ist/war.
Ich kann mir nur vorstellen, dass da ein Berechtigungsproblem am Server besteht.

LG

Peter