Verbindung wird bereits verwendet
Susanne Senger
ich habe ein Formular - kein Datagrid - das Daten aus einer geöffneten
Datenbank bekommt (einlesen über ADO, kein Problem, es sollen auch immer nur
Infos aus einen Datensatz im Formular angezeigt werden.
Die DB-Infos kommen aus dem aktuell markierten Datensatz der geöffneten DB.
Eigentlich bin ich sicher, dass ich, sobald die Daten im Formular stehen,
die Verbindung wieder gekappt habe (set cnn = nothing) - beim Klick auf eine
Schaltfläche wird die Verbindung wieder hergestellt und der aktuell
markierte DS eingelesen.
Trotzdem bekomme ich, wenn ich eine andere DB öffne, die Meldung
"Laufzeitfehler -214745259(80004005): Konnte nicht verwendet werden; Datei
wird bereits verwendet."
Hat jemand eine Idee, wie ich das vermeiden kann, bzw. wie ich sicherstellen
kann, dass alle Verbindungen tatsächlich wieder zu sind? Vielen Dank.
Susanne
Peter Götz
> ich habe ein Formular - kein Datagrid - das Daten aus einer geöffneten
> Datenbank bekommt (einlesen über ADO, kein Problem, es sollen auch immer
nur
> Infos aus einen Datensatz im Formular angezeigt werden.
>
> Die DB-Infos kommen aus dem aktuell markierten Datensatz der geöffneten
DB.
wo ist denn dieser Datensatz aktuell markiert?
> Eigentlich bin ich sicher, dass ich, sobald die Daten im Formular stehen,
> die Verbindung wieder gekappt habe (set cnn = nothing) - beim Klick auf
eine
> Schaltfläche wird die Verbindung wieder hergestellt und der aktuell
> markierte DS eingelesen.
Wie oft in welchem Zeitraum passiert denn dieses set cnn = nothing und das
nachfolgende Wiederherstellen der Verbindung?
>
> Trotzdem bekomme ich, wenn ich eine andere DB öffne, die Meldung
> "Laufzeitfehler -214745259(80004005): Konnte nicht verwendet werden; Datei
> wird bereits verwendet."
Das heisst, dass irgendein anderes Connection-Objekt in Deinem Projekt diese
andere DB exklusiv geöffnet hat, oder eine andere Anwendung auf Deinem
Rechner oder auch ein ganz anderer Benutzer auf einem anderen Rechner diese
DB exklusiv geöffnet hat.
> Hat jemand eine Idee, wie ich das vermeiden kann, bzw. wie ich
sicherstellen
> kann, dass alle Verbindungen tatsächlich wieder zu sind? Vielen Dank.
Die einfachste und in den meisten Fällen beste Methode ist, mit einem
"einzigen" Connection-Objekt zu arbeiten und alle notwendigen Recordsets und
Command-Objekte über diese Connection arbeiten zu lassen. Ein ständiges
Öffnen und Trennen kann, aber muss in vielen Fällen nicht unbedingt sinnvoll
sein.
Normalerweise sollte in der von Dir genannten Fehlermeldung aber auch
stehen, von welchem Benutzer diese DB-Datei benutzt wird. Das wäre dann ja
schon mal ein Anhaltspunkt.
Gruß aus St.Georgen
Peter Götz
p.g...@gssg.de
www.gssg.de (mit VB-Tips u. Beispielprogrammen)
Stephan Oppermann
>Die DB-Infos kommen aus dem aktuell markierten Datensatz der geöffneten DB.
>Eigentlich bin ich sicher, dass ich, sobald die Daten im Formular stehen,
>die Verbindung wieder gekappt habe (set cnn = nothing) - beim Klick auf eine
>Schaltfläche wird die Verbindung wieder hergestellt und der aktuell
>markierte DS eingelesen.
cnn.close
cnn.open
Warum immer das Objekt zerstören?
Gruß Oppi
Gerd-Rainer Birnbaum
Hallo Peter,
"Peter G?z" <p.g...@gssg.de> wrote in message news:<uqLpb0hNCHA.1408@tkmsftngp12>...
> >
> > Trotzdem bekomme ich, wenn ich eine andere DB öffne, die Meldung
> > "Laufzeitfehler -214745259(80004005): Konnte nicht verwendet werden; Datei
> > wird bereits verwendet."
>
> Das heisst, dass irgendein anderes Connection-Objekt in Deinem Projekt diese
> andere DB exklusiv geöffnet hat, oder eine andere Anwendung auf Deinem
> Rechner oder auch ein ganz anderer Benutzer auf einem anderen Rechner diese
> DB exklusiv geöffnet hat.
>
bitte entschuldigt, wenn ich mich in euren Thread einschalte, aber ich
habe ein ähnliches Problem.
In einem Thread (ein paar Zeilen über diesem hier) habe ich gefragt,
wie ich eine Excel Datei in eine Access Datenbank speichern kann und
ein freundlicher Mensch von Microsoft hat mir einen Artikel aus der
Knowledgebase genannt, mit dem ich die Lösung über einen ADOStream
bekomme.
Ich habs probiert und bekomme fast die gleiche Fehlermeldung:
"Run-time error '-2147467259 (80004005)':
Die Anwendung kann nicht gestartet werden. Die Informationsdatei für
die Arbeitsgruppe fehlt oder ist exklusiv von einem anderen Benutzer
geöffnet."
Dummerweise bekomme ich auch eine Fehlermeldung, wenn ich den Help
Button unter der Fehlermeldung klicke *grummel*.
Ich muß dazu sagen, das ADO für mich Neuland ist. Meine bisherigen
Projekte nutzen DAO und auch in dem aktuellen Projekt wollte ich per
ADO nur die Excel Datei in die Access db bekommen. (Und jetzt hab ich
den Salat :-)
Bei der Fehlermeldung wundert mich, das die negative Zahl zwar
unterschiedlich, die geklammerte aber gleich ist. Muß ich das
verstehen ?!?
Und was ist die Informationsdatei der Arbeitsgruppe ? Ist das eine
andere Datei, wie die für DAO (System.mdw oder wars ..mda ?) ?
Bei mir sind definitiv alle anderen Verbindungen zur db zu und da ich
zur Zeit nur mit einer lokalen db arbeite, kann auch kein anderer
Benutzer am Draht sein.
Nun hab ich viele (möglicherweise dumme) Fragen gestellt, aber
vielleicht hat ja jemand eine Idee, die auch Susanne weiterhilft.
Gruß
Gerd-Rainer Birnbaum
Peter Götz
> > > Trotzdem bekomme ich, wenn ich eine andere DB öffne, die Meldung
> > > "Laufzeitfehler -214745259(80004005): Konnte nicht verwendet werden;
Datei
> > > wird bereits verwendet."
um Deine Frage nach der Bedeutung der Fehlernummer und der dahinterstehenden
in Klammern eingeschlossenen gleich vorweg zu beantworten:
Die erste Zahl, ausserhalb der Klammer ist die Fehlernummer in dezimaler
Schreibweise, die zweite, in Klammern stehende, ist die selbe Zahl nur in
hexadezimaler Schreibweise.
Beim obigen Beispiel von Susanne, sieht man auch gleich, dass ihr offenbar
ein Tippfehler beim Abschreiben der ersten (negativen) Zahl unterlaufen ist.
Denn die Zahl 214745259 wäre in hexadezimaler Schreibweise ein &hF3333F55
Debug.print Hex$(-214745259) -->> F3333F55
andersherum:
Debug.print &h80004005 -->> -2147467259
Statt, wie Susanne geschrieben hat -214745259, dürfte die Fehlernummer
tatsächlich -2147467259 gewesen sein.
Die hexadezimale Schreibweise ist wesentlich anschaulicher und eignet sich
auch besser als Suchbegriff in der Online-Hilfe und sonstigen
Dokumentationen. Tatsächlich sind Fehlernummern immer positive Ganzzahlen
vom Typ UnsignedLong. Da es diesen Datentyp in VB aber nicht gibt, packt VB
diese Fehlernummern in den VB-Datentyp Long und dabei ergeben sich dann für
Werte > &h7FFFFFFF beim VB-Datentyp Long negative dezimale Zahlenwerte.
Debug.Print &h7FFFFFFF -->> 2147483647
der nächsthöhere Wert für UnsignedLong wäre dann &h80000000
Debug.print &h80000000 -->> -2147483648
Debug.print &h80000001 -->> -2147483647
Debug.print &h80000002 -->> -2147483646
usw.
Dazu solltest Du Dir die Online-Hilfe zum Thema "DatenTypen" und deren
Wertebereiche ansehen.
> > Das heisst, dass irgendein anderes Connection-Objekt in Deinem Projekt
diese
> > andere DB exklusiv geöffnet hat, oder eine andere Anwendung auf Deinem
> > Rechner oder auch ein ganz anderer Benutzer auf einem anderen Rechner
diese
> > DB exklusiv geöffnet hat.
> >
>
> bitte entschuldigt, wenn ich mich in euren Thread einschalte, aber ich
> habe ein ähnliches Problem.
>
> In einem Thread (ein paar Zeilen über diesem hier) habe ich gefragt,
> wie ich eine Excel Datei in eine Access Datenbank speichern kann und
> ein freundlicher Mensch von Microsoft hat mir einen Artikel aus der
> Knowledgebase genannt, mit dem ich die Lösung über einen ADOStream
> bekomme.
>
> Ich habs probiert und bekomme fast die gleiche Fehlermeldung:
> "Run-time error '-2147467259 (80004005)':
Du hast die gleiche Fehlermeldung bekommen, nur eben auch richtig (ohne
Tippfehler) abgeschrieben.
> Die Anwendung kann nicht gestartet werden. Die Informationsdatei für
> die Arbeitsgruppe fehlt oder ist exklusiv von einem anderen Benutzer
> geöffnet."
Das bedeutet, dass Deine Access.mdb auf benutzerebene (mit einer System.mdb)
geschützt ist und entweder die zugehörige System.mdb nicht gefunden werden
konnte, oder aber irgendein Benutzer, das kannst Du selbst (über eine andere
Connection), oder auch ein anderer Benutzer sein, die Datenbank exklusiv
geöffnet hat.
> Dummerweise bekomme ich auch eine Fehlermeldung, wenn ich den Help
> Button unter der Fehlermeldung klicke *grummel*.
Verstehe ich nicht so ganz.
Welche Fehlermeldung unter welchem Button?
> Ich muß dazu sagen, das ADO für mich Neuland ist. Meine bisherigen
> Projekte nutzen DAO und auch in dem aktuellen Projekt wollte ich per
> ADO nur die Excel Datei in die Access db bekommen. (Und jetzt hab ich
> den Salat :-)
Ja, ja, das kommt davon. ;-))
> Bei der Fehlermeldung wundert mich, das die negative Zahl zwar
> unterschiedlich, die geklammerte aber gleich ist. Muß ich das
> verstehen ?!?
siehe oben, einfach ein ganz simpler, jedem mal unterlaufender Tippfehler.
> Und was ist die Informationsdatei der Arbeitsgruppe ?
Du musst selbst wissen, mit welcher "System.mdw" Deine Access-Datenbank
*.mdb geschützt ist.
> Ist das eine
> andere Datei, wie die für DAO (System.mdw oder wars ..mda ?) ?
Ja, genau diese Datei ist damit gemeint.
>
> Bei mir sind definitiv alle anderen Verbindungen zur db zu und da ich
> zur Zeit nur mit einer lokalen db arbeite, kann auch kein anderer
> Benutzer am Draht sein.
Dann ist offenbar Deine *.mdb an eine *.mdw / *.mda gekoppelt und diese wird
nicht gefunden. In diesem Fall musst Du ADO den Pfad zu dieser *.mdw
mitteilen und falls es einen Passwortschutz gibt, dieses Passwort ebenfalls.
Das Öffnen Deiner Connection zur *.mdb könnte dann etwa so aussehen:
Dim strFileName As String
Dim strSysDBName As String
strFileName = "C:\Verzeichnis\DB.mdb"
strSysDBName = "C:\Verzeichnis\System.mdw"
With CNN
.Provider = "Microsoft.Jet.OLEDB.4.0"
.Properties("Data Source").Value = strDatabaseName
.Properties("Jet OLEDB:System database").Value = strSysDBName
.Properties("Password").Value = "Passwort"
.Properties("User ID").Value = "Benutzerkennung"
.Open
End With
Weitere Programmbeispiele zum Thema ADO findest Du unter
www.gssg.de -> VB-Tips -> Datenbank
> Nun hab ich viele (möglicherweise dumme) Fragen gestellt, aber
> vielleicht hat ja jemand eine Idee, die auch Susanne weiterhilft.
Wenn man nicht fragt, wird man's nie erfahren. ;-)
Ich würde Dir aber auch empfehlen, Dich erst mal anhand der
ADO-Dokumentation (z.B. ADO210.CHM und/oder ADO260.CHM) mit den vielfältigen
Möglichkeiten von ADO vertraut zu machen. Zumindest die Objekte Connection,
Recordset und Command mit all ihren Eigenschaften und Methoden solltest Du
schon verstanden haben, bevor Du Dich daran machst, ADO in Deinem Programm
zu nutzten.
Das verstehen der verschiedenen Datentypen und ihrer Wertebereiche wäre
schon auch sehr wichtig und der sichere Umgang mit den wichtigsten
Zahlensystem Dezimal, Dual, Oktal und Hexadezimal macht den
Programmieralltag gewiss auch wesentlich effektiver.
Ohne diese Grundlagen wird das immer ein "Stochern im Nebel" bleiben.
Gerd-Rainer Birnbaum
zunächst mal vielen Dank, daß Du Dir die Zeit genommen hast, sooooo
ausführlich zu antworten.
"Peter G?z" <p.g...@gssg.de> wrote in message news:<ukOKQC7NCHA.1620@tkmsftngp10>...
unter vielem Anderen :-) :
>
> > Dummerweise bekomme ich auch eine Fehlermeldung, wenn ich den Help
> > Button unter der Fehlermeldung klicke *grummel*.
>
> Verstehe ich nicht so ganz.
> Welche Fehlermeldung unter welchem Button?
Die Fehlermeldung in der Entwicklungsumgebung (die oben beschriebene).
Unter der kannst Du doch normalerweise mit dem Help Button direkt auf
die Fehlerbeschreibung in der Online-Hilfe springen. Das funktionierte
bei diesem Problem leider nicht.
> Dann ist offenbar Deine *.mdb an eine *.mdw / *.mda gekoppelt und diese wird
> nicht gefunden. In diesem Fall musst Du ADO den Pfad zu dieser *.mdw
> mitteilen und falls es einen Passwortschutz gibt, dieses Passwort ebenfalls.
> Das Öffnen Deiner Connection zur *.mdb könnte dann etwa so aussehen:
>
> Dim strFileName As String
> Dim strSysDBName As String
>
> strFileName = "C:\Verzeichnis\DB.mdb"
> strSysDBName = "C:\Verzeichnis\System.mdw"
>
> With CNN
> .Provider = "Microsoft.Jet.OLEDB.4.0"
> .Properties("Data Source").Value = strDatabaseName
> .Properties("Jet OLEDB:System database").Value = strSysDBName
> .Properties("Password").Value = "Passwort"
> .Properties("User ID").Value = "Benutzerkennung"
> .Open
> End With
>
Nochmals vielen Dank ! Dein Beispiel hat mir sehr geholfen. Darf ich
Dich trotzdem noch etwas fragen:
Wenn ich das Datenbankkennwort aus meiner Datenbank entferne, dann
klappt es jetzt bei mir. Wenn ich die Datenbank direkt mit Access 97
öffne, mußte ich vorher das Datenbankkennwort eingeben.
Zur besseren Beschreibung hier mal ein Schnipsel code:
With cn
.Provider = "Microsoft.Jet.OLEDB.3.51"
' .Provider = "Microsoft.Jet.OLEDB.4.0"
.Properties("Data Source").Value = PlanManCtrl.Databasepath
' .Properties("Jet OLEDB:System database").Value = App.path +
"\system.mdw"
.Properties("Jet OLEDB:System database").Value =
"C:\WINNT\System32\system.mdw"
' .Properties("User ID").Value = "Admin"
.Properties("Password").Value = "bf109e"
.Open
End With
Ohne Password (dann natürlich geREMt) klappt es jetzt. Mich wundert
allerdings, das es nicht funktioniert, wenn ich den - eigentlich
standardmäßigen - Pfad zur System.mdw nicht angebe ?!? Aber egal.
Wenn ich die Datenbank dann wieder (direkt mit Access 97) mit einem
Kennwort schütze, dann bekomme ich wieder eine Fehlermeldung "Kein
zulässiger Kontoname oder kein zulässiges Kennwort." mit genau dem
oben gezeigten Codeschnipsel.
Also mache ich doch immer noch etwas falsch ? Ich hab mein System
schon nach weiteren System.mdw's durchsucht, aber nichts gefunden.
BTW: Wo kann ich eigentlich die möglichen Properties ("Password",
"UserID" usw.) nachlesen ? In der ADO Online-Hilfe hab ich nichts
gefunden (aber allzu lange hab ich auch nicht gesucht :-))
> Wenn man nicht fragt, wird man's nie erfahren. ;-)
Eben :-)
> Ich würde Dir aber auch empfehlen, Dich erst mal anhand der
> ADO-Dokumentation (z.B. ADO210.CHM und/oder ADO260.CHM) mit den vielfältigen
> Möglichkeiten von ADO vertraut zu machen.
Das werd ich sicher tun. ADO fängt an, mir zu gefallen. Bisher habe
ich eben nur mit DAO gearbeitet und mit Datenbanken noch nicht viel
allzuviel gemacht.
(Normalerweise schreibe ich mehr Meß- und Auswerteprogramme.)
> Das verstehen der verschiedenen Datentypen und ihrer Wertebereiche wäre
> schon auch sehr wichtig und der sichere Umgang mit den wichtigsten
> Zahlensystem Dezimal, Dual, Oktal und Hexadezimal macht den
> Programmieralltag gewiss auch wesentlich effektiver.
> Ohne diese Grundlagen wird das immer ein "Stochern im Nebel" bleiben.
OK :-) Die Dinge kenne ich alle, auch wenn Du's nicht glauben wirst.
Die Frage nach der Fehlermeldung in hex und dez Schreibweisen war
dusselig, das geb ich gerne zu. Aber Susannes Fehler und mein
paralleler (eigentlich gleicher) Fehler haben mich wohl verwirrt.
Nochmals vielen Dank ! Es ist schön, das es Leute in solchen Foren
gibt, die einem "Verwirrten" auf seine vielen Fragen schnell und
kompetent helfen {einschleimen OFF}.
Gruß
Gerd-Rainer
Peter Götz
die Geschichte mit Deinem Passwort verstehe ich noch nicht so ganz.
Welche Art von Passwortschutz verwendest Du denn nun konkret für Deine
Access.mdb:
1.) gar kein Passwort?
2.) internes Datenbankkennwort (ohne System.mdb)?
3.) Kennwort auf Benutzerebene (mit System.mdb)?
Gerd-Rainer Birnbaum
"Peter Götz" <p.g...@gssg.de> schrieb im Newsbeitrag
news:<uR7wrmSOCHA.1572@tkmsftngp13>...
> Hallo Gerd-Rainer,
>
> die Geschichte mit Deinem Passwort verstehe ich noch nicht so ganz.
>
> Welche Art von Passwortschutz verwendest Du denn nun konkret für Deine
> Access.mdb:
>
> 1.) gar kein Passwort?
>
> 2.) internes Datenbankkennwort (ohne System.mdb)?
internes Datenbankkennwort, ohne das ich bei der Eingabe überhaupt einen
Benutzer angeben muß.
Dabei ist mir nicht klar, ob ich die System.mdw überhaupt brauche ?!?
Aber ohne Angabe der System.mdw im Code gibts eine Fehlermeldung.
Wie gebe ich denn ein internes, nicht benutzerabhängiges Kennwort an ?
Gruß
Gerd-Rainer
Peter Götz
> > Welche Art von Passwortschutz verwendest Du denn nun konkret für Deine
> > Access.mdb:
> >
> > 1.) gar kein Passwort?
> >
> > 2.) internes Datenbankkennwort (ohne System.mdb)?
>
> internes Datenbankkennwort, ohne das ich bei der Eingabe überhaupt einen
> Benutzer angeben muß.
> Dabei ist mir nicht klar, ob ich die System.mdw überhaupt brauche ?!?
> Aber ohne Angabe der System.mdw im Code gibts eine Fehlermeldung.
> Wie gebe ich denn ein internes, nicht benutzerabhängiges Kennwort an ?
Für eine Access.mdb gibt es zwei völlig unterschiedliche Arten von
Schutzmechanismen, die einzeln oder auch zusammen verwendet werden können.
Internes Datenbankkennwort:
Die Datenbank kann mit Access oder von einem per DAO oder ADO zugreifenden
Programm nur geöffnet werden, wenn ein gültiges Datenbankkennwort übergeben
worden ist. Hierfür ist keine System.mdw erforderlich. Das Datenbankkennwort
befindet sich in verschlüsselter Form in der zu öffnenden *.mdb selbst.
Eine mit einem Datenbankkennwort geschützte *.mdb wird so geöffnet:
Dim Cnn As ADODB.Connection
Dim strDBFileName As String
Dim strDBPwd As String
' vollst. Pfad zur Datenbankdatei *.mdb
strDBFileName = "C:\Verzeichnis\DB.mdb"
' falls die DB mit einem Datenbankkennwort geschützt ist.
strDBPwd = "DeinDBKennwort"
' Instanz eines Connectionobjektes erstellen
Set Cnn = New ADODB.Connection
' *** Connection öffnen
With Cnn
.Provider = "Microsoft.Jet.OLEDB.4.0"
.Properties("Data Source") = strDBFileName
If Len(DBPassWord) Then
.Properties("Jet OLEDB:Database Password") = strDBPwd
End If
.CursorLocation = adUseClient
.Mode = adModeShareDenyNone
.Open
End With
Schutz auf Benutzerebene:
Hierbei können abhängig von der jeweiligen Benutzerkennung unterschiedliche
Rechte für den Zugriff auf die verschiedenen Datenbankinhalte vergeben
werden. Es kann z.B. festgelegt werden welcher Benutzer welche Tabellen z.B.
nur lesen darf und welche ein anderer Benutzer lesen und beschreiben darf.
Für diesen Schutzmechanismus ist zu der *.mdb gehörende System.mdw
erforderlich.
Wie bei einer solchen *.mdb die Benutzerkennung und das zugehörige Passwort
zu übergeben sind, habe ich Dir im ersten Posting gezeigt.
Gerd-Rainer Birnbaum
meinen besten Dank für Deine wertvollen Auskünfte !!
Da ich seit heute im Urlaub bin, kann ich sie leider erst am 2. September
ausprobieren :-))
Nochmals vielen Dank !
Viele Grüße
Gerd-Rainer Birnbaum