Datenbank ist plötzlich schreibgeschützt (Unterschied CDatabase::Open zu OpenEx??)
-
Hi,
habe es mal auf die schnelle probiert und keine Probleme.
Kann es sein, das deine DSN nicht auf die richtige Datenbank zeigt?
Vielleicht steht die DSN ja auf die master Datenbank und der Benutzer mit dem
du zugreifst hat deshalb kein Schreibrecht. Du kannst im Connectionstring
nach mit angeben, welche Datenbank er verwenden soll:if (!m_dbAd.OpenEx("DSN=ACR;UID=anyusr;PWD=anyusr;DATABASE=MeineDB;", CDatabase::noOdbcDialog)) if ( m_dbAd.CanUpdate() ) TRACE(_T("Datenbankverbindung hat Schreibrecht.\n"));
Gruss
EB
-
Die DSN ist vollkommen okay. Ich muss nur die beiden Zeilen austauschen und mit Open geht es und mit OpenEx nicht.
m_dbAd.OpenEx("DSN=meineDB;UID=sa;PWD=manager", CDatabase::noOdbcDialog); m_dbAd.Open("meineDB", FALSE, FALSE, "ODBC;UID=sa;PWD=manager");
-
Dein Problem habe ich schon verstanden. Aber Du möchtest doch herausfinden, wo
der Unterschied liegt, oder? Was liefert denn GetConnect() für einen Connectionstring zurück, wenn du die DSN mit CDatabase::forceOdbcDialog angibst? Ist der anders als Deiner?
Was liefert CanUpdate() zurück?
Vielleicht sind ja auch deine ODBC-Treiber veraltet und du hast einen Bug.
Ist MDAC 2.8 Installiert?
Welches ist die default Datenbank in deiner DSN-Konfiguration?
Ist es notwendig mit dem Benutzer sa (security agent) auf die Datenbank zuzugreifen?Also einige Stellen wo es dran liegen kann. Das es mit Open() klappt, warum
auch immer, aber das versuchen wir ja herauszufinden
-
Was EB sagt kann ich sehr gut nachvollziehen, ich hatte als StandardDB eine DB die da hieß 4862TRW wenn ich die StandardDB mit dem Open angesprochen hab (also beim Open weggelassen) dann hab ich andauernd connectiontimeouts etc bekommen, hab ich aber nicht die Standard gewählt sondern direkt 4862TRW dann gings also es lohnt sich glaube ich schon da nochmal rein zu schauen. Welche DB sprichst du denn im CreateDSN an. Da sollte am besten auch nicht einfach nur standard drin stehen denn das hat bei mir merkwürdiges verursacht auf meinem Rechner lief es so einwandfrei auf anderen gar nicht.
-
EB schrieb:
Was liefert denn GetConnect() für einen Connectionstring zurück, wenn du die DSN mit CDatabase::forceOdbcDialog angibst? Ist der anders als Deiner?
OpenEx mit CDatabase::noOdbcDialog:
ODBC;DSN=ad3;UID=sa;PWD=manager;APP=Anwendung Ad3;WSID=MeinPC;DATABASE=ad3
OpenEx mit CDatabase::forceOdbcDialog:
ODBC;DSN=ad3;UID=sa;PWD=manager;APP=Anwendung Ad3;WSID=MeinPC;DATABASE=ad3
Open:
ODBC;DSN=ad3;UID=sa;PWD=manager;APP=Anwendung Ad3;WSID=MeinPC;DATABASE=ad3
Also alle identisch.EB schrieb:
Was liefert CanUpdate() zurück?
Mit Open: TRUE
Mit OpenEx: TRUEEB schrieb:
Vielleicht sind ja auch deine ODBC-Treiber veraltet und du hast einen Bug.
Ist MDAC 2.8 Installiert?Wie finde ich das heraus?
EB schrieb:
Welches ist die default Datenbank in deiner DSN-Konfiguration?
ad3, also die, auf die ich zugreifen will.
Die wurde angelegt mit:CString szDriver = "SQL Server"; CSqlConfigString arrAttributes; arrAttributes.Add("DSN=ad3"); arrAttributes.Add("DESCRIPTION=Datenbank"); arrAttributes.Add("SERVER=(local)"); arrAttributes.Add("DATABASE=ad3"); // Sicherheitshalber löschen: SQLConfigDataSource(NULL, ODBC_REMOVE_DSN, szDriver, arrAttributes); // Jetzt erstellen if (SQLConfigDataSource(NULL, ODBC_ADD_DSN, szDriver, arrAttributes)) { m_dbAd.Open("ad3", FALSE, FALSE, "ODBC;UID=sa;PWD=manager"); }
EB schrieb:
Ist es notwendig mit dem Benutzer sa (security agent) auf die Datenbank zuzugreifen?
Jein... ich war bisher zu faul, mir einen anderen User anzulegen.
Bevor ich mich mit Userrechten rumschlage habe ich noch genug andere Probleme zu lösen.
-
Polofreak schrieb:
Was EB sagt kann ich sehr gut nachvollziehen, ich hatte als StandardDB eine DB die da hieß 4862TRW wenn ich die StandardDB mit dem Open angesprochen hab (also beim Open weggelassen) dann hab ich andauernd connectiontimeouts etc bekommen, hab ich aber nicht die Standard gewählt sondern direkt 4862TRW dann gings also es lohnt sich glaube ich schon da nochmal rein zu schauen. Welche DB sprichst du denn im CreateDSN an. Da sollte am besten auch nicht einfach nur standard drin stehen denn das hat bei mir merkwürdiges verursacht auf meinem Rechner lief es so einwandfrei auf anderen gar nicht.
Das habe ich nicht verstanden.
Also, was geht und was nicht? Habe ich davon eine Sache schon gepostet? Zeig bitte mal.
Was wäre das andere?
-
Hast schon gepostet was ich sehen wollte da wo du
arrAttributes.add("DATABASE=
machst, kannst du auch danach
Standard
eingeben, geht auch hin und wieder mal aber eben nicht immer. du machst es schon richtig, dass du da direkt ad3 angibst!
Ich weiß nciht obs geht aber probiers doch mal so:
CString szDriver = "SQL Server"; CSqlConfigString arrAttributes; arrAttributes.Add("DSN=ad3"); arrAttributes.Add("DESCRIPTION=Datenbank"); arrAttributes.Add("SERVER=(local)"); arrAttributes.Add("DATABASE=ad3"); // Sicherheitshalber löschen: SQLConfigDataSource(NULL, ODBC_REMOVE_DSN, szDriver, arrAttributes); // Jetzt erstellen if (SQLConfigDataSource(NULL, ODBC_ADD_DSN, szDriver, arrAttributes)) { m_dbAd.Open("DSN=ad3;UID=sa;PWD=manager;DATABASE=ad3;"); }
-
Polofreak schrieb:
Ich weiß nciht obs geht aber probiers doch mal so:
m_dbAd.Open("DSN=ad3;UID=sa;PWD=manager;DATABASE=ad3;");
Aber Open funktioniert doch.
Wieso soll ich das ändern? OpenEx geht ja nicht und als ich das DATABASE= da eingebaut habe, war es immernoch mit Schreibschutz.
-
Sorry mein Fehler!
Hm doof. Tut mir leid da kann ich dir glaub dann doch nicht mehr helfen.
TZORRY!EDIT: was spricht dann gegen Open?? erscheint denn bei dir immernoch ein Dialog wenn du es wie in obigem Post machst? Du hast ja geschrieben du willst es nciht mit open weil ein Dialog kommt also bei mir kommt keiner mit Open
-
Ich habe mich nochmal etwas mit dem Problem beschäftigt.
Leider habe ich bei mir kein Problem.System: Windows XP Pro / MSDE 8.00.760(SP3)
Hier mein Zugriffcode:
SQLConfigDataSource(NULL, ODBC_REMOVE_DSN, _T("SQL Server"), _T("DSN=ad3\0SERVER=127.0.0.1\0DATABASE=TestDB\0\0")); VERIFY(SQLConfigDataSource(NULL, ODBC_ADD_DSN, _T("SQL Server"), _T("DSN=ad3\0SERVER=127.0.0.1\0DATABASE=TestDB\0\0"))); CDatabase db; if ( db.OpenEx(_T("DSN=ad3;UID=sa;PWD=manager;DATABASE=TestDB;"), 0) ) { if ( db.CanUpdate() ) { TRACE(_T("Database Read/Write access.\n")); CDBMember rs(&db); if ( rs.Open(CRecordset::dynaset, _T("SELECT * FROM member")) ) { while ( !rs.IsEOF() && !rs.IsBOF() ) { if ( rs.CanUpdate() ) { TRACE(_T("Recordset Read/Write access.\n")); rs.Edit(); TRACE3(_T("FirstName: %s - LastName: %s - Street: %s\n"), rs.m_LastName, rs.m_FirstName, rs.m_Street); rs.m_LastName = "Mustermann"; rs.Update(); } rs.MoveNext(); } rs.Close(); } } db.Close(); }
Hier mal die wichtigsten Debug-Ausgaben:
Warning: ODBC Success With Info, Changed database context to 'TestDB'. State:01000,Native:5701,Origin:[Microsoft][ODBC SQL Server Driver][SQL Server] Changed language setting to us_english. State:01000,Native:5703,Origin:[Microsoft][ODBC SQL Server Driver][SQL Server] DBMS: Microsoft SQL Server Version: 08.00.0760 ODBC Driver Manager Version: 03.52.0000 Database Read/Write access. Recordset Read/Write access. FirstName: Mustermann Recordset Read/Write access. FirstName: Mustermann
Also irgendwie fast Identisch, allerdings funktioniert es bei mir problemlos.
CDBMember ist von CRecordset mit der Option 'dynaset' mit dem Klassenwizard
abeleitet. Ich denke das ist bei Dir ebenfalls so.Um deine MDAC-Version zu prüfen, gibt es ein Tool von Microsoft allerdings
must dein XP dafür am Genuine-Projekt teilnehmen.Aktuell ist MDAC 2.8 SP1.
Sollte über WindowsUpdate zu bekommen sein. Ansonsten das SDK oder Redistributable herunterladen.
Mehr kann ich leider wohl auch nicht weiterhelfen, denn sonst scheint es
ein Problem auf deiner Maschine zu sein.Gruss
EB
-
Dankeschön, ich gehe das Morgen mal durch.
Ich habe kein XP, nur 2000 - mal gucken ob es da auch was gibt.
Sollte es tatsächlich an meiner Installation liegen, dann teste ich es mal auf dem Zielsystem (Win98).
Wenn es da geht muss ich im Debugmodus eben Open nehmen und im Release OpenEx.
-
Mir ist heute Morgen noch etwas eingefallen und das funktioniert.
Also:
Ich teste mit dem OpenEx, ob die Datenbank verbunden ist und hinterher, wenn es auf jeden Fall funktioniert, mache ich wieder zu und dann mit Open auf.try { m_dbAd.OpenEx("DSN=meineDB;UID=sa;PWD=manager", CDatabase::noOdbcDialog); } catch (CDBException* p) { // Siehe Post weiter oben // Jetzt erstellen if (!SQLConfigDataSource(NULL, ODBC_ADD_DSN, szDriver, arrAttributes)) { p->ReportError(); p->Delete(); return FALSE; } p->Delete(); } m_dbAd.Close(); m_dbAd.Open("meineDB", FALSE, FALSE, "ODBC;UID=sa;PWD=manager");
-
Nicht 100%ig schön, aber wenn es so geht
-
Es geht leider nicht immer.
Ich müsste noch irgenwie den User, das Passwort, das Protokoll und die Treibersprache mitgeben.
Irgendwelche Ideen, wie das aussehen muss? Try&Error war bei diesem Befehl irgendwie nie besonders erfolgversprechend.
-
Hallo,
bin gerade selbst über dieses Problem gefallen. Die Beiträge im Forum haben mir sehr geholfen. Des Rätsels Lösung (bei mir): Der Recordset muss ein Dynaset sein, kein!! Snapshot. Man kann dies sicherstellen im Konstruktor des Recordsets:
....
m_nFields = 6;
//}}AFX_FIELD_INIT
m_nDefaultType = dynaset;
....Auch ich verwende OpenEx (mit vollständigem Connect-String, d.h. es gibt keinen Eintrag im ODBC-Admin mehr, die Verbindung wird vollständig dynamisch erzeugt).
Grüße
CS
-
Welche VS Version nutzt du?
Im 6er hatte ich nämlich auch immer Probs mit der OpenEx
-
cschroed schrieb:
Der Recordset muss ein Dynaset sein, kein!! Snapshot.
Ahja, nur arbeite ich an der Stelle rein mit CDatabase.
Aber danke für eine weitere Lösung.Pellaeon schrieb:
Welche VS Version nutzt du?
Im 6er hatte ich nämlich auch immer Probs mit der OpenExIch arbeite mit VC6 und erstelle die Release mit VC7. Vielleicht sollte ich das nochmal austesten.
-
Hallo mir hat eure diskussion hier viel geholfen, ich hatte das selbe problem, mit Open klappt es aber nun und dabei hab ich es auch belassen, keine ahnung wo der unterschied liegen könnte, habe ein bisschen geguckt aber nichts gefunden.
Ciao