Archiv verlassen und diese Seite im Standarddesign anzeigen : [MySQL] Native error code 0x80040e21
FlashBurn
2014-11-25, 10:48:28
Moin,
bei einem Kunden läuft ein MySQL Server und auf diesen wird über den MySQL Connector/ODBC zugegriffen. Das funktioniert auch alles soweit, nut nach einer unbestimmten Zeit (mehrere Stunden/Tage) kann eine bestimme Abfrage, die sonst immer funktioniert, nicht mehr ausgeführt werden und führt zu folgendem Fehler:
Native error code -2147217887 0x80040e21
Microsoft OLE DB Provider for ODBC Drivers:
Der ODBC-Treiber unterstützt die angeforderten Eigenschaften nicht.
Zur besseren Fehleranalyse lasse ich mir auch immer die Abfrage mit ausgeben, aber die Abfrage ist korrekt und funktioniert ja auch sonst, nur halt manchmal nicht.
Wie kann ich dem weiter auf die Schliche kommen?
Problem ist vorallem das es nicht einfach reproduzierbar ist und selbst dann komme ich nicht weiter, weil auf meiner Programmseite alles richtig ist. Außer das ich halt bei der Abfrage diesen Fehler bekomme.
Wieder mal erwartet jemand, eine Glaskugel zu haben, und alle Infos zu haben. :rolleyes:
Welche Versionen (OS, Programm, ODBC Treiber....)? Wer greift wie darauf zu...
Schon mal den Client aktualisiert?
Und warum meldet sich der OLE DB Provider von Microsoft? Der sollte gar nichts damit zu tun haben, da OLE DB != ODBC. OLE DB ist der Nachfolger von ODBC, die Schnittstelle ist hier erweitert worden. Muß man über ODBC gehen? Wenn nein, welchsle auf JDBC.
FlashBurn
2014-11-25, 15:23:38
Wieder mal erwartet jemand, eine Glaskugel zu haben, und alle Infos zu haben. :rolleyes:
Sorry, ich hatte die Wage Hoffnung das es aussagekräftige Fehlermeldungen gibt ;)
Welche Versionen (OS, Programm, ODBC Treiber....)? Wer greift wie darauf zu...
Sollte Windows 7 Professional und MySQL Connector/ODBC 5.2.6 sein. Das Programm ist in Labwindows/CVI geschrieben. Da die Abfrage aber immer die gleiche ist und das Problem sporadisch auftaucht gehe ich von einem Problem im ODBC Connector aus. Was meinst du mit wer greift wie darauf zu?
Schon mal den Client aktualisiert?
Mit Client meinst du den ODBC Connector? Wenn ja, der wurde noch nicht aktualisiert. Das ist leider auch nicht so einfach. Ich will nicht auf gut Glück bei einem 24/7 System ein Update machen was wieder einen Rattenschwanz nach sich zieht (Updates aller beteiligten Programme). Das mache ich wenn ich mir sicher bin das es was bringt.
Und warum meldet sich der OLE DB Provider von Microsoft? Der sollte gar nichts damit zu tun haben, da OLE DB != ODBC. OLE DB ist der Nachfolger von ODBC, die Schnittstelle ist hier erweitert worden. Muß man über ODBC gehen? Wenn nein, welchsle auf JDBC.
Es wird aus einem Programm heraus auf die Datenbank über ODBC zugegriffen. Dies kann nicht/bzw. nicht mehr anders gemacht werden.
Sollte Windows 7 Professional und MySQL Connector/ODBC 5.2.6 sein. Das Programm ist in Labwindows/CVI geschrieben. Da die Abfrage aber immer die gleiche ist und das Problem sporadisch auftaucht gehe ich von einem Problem im ODBC Connector aus. Was meinst du mit wer greift wie darauf zu?
Sprich, wer ist Client (wer greift wie zu, hier Labwindows mit ODBC als Client), wer ist Host/Server, sprich die Datenbank. Oftmals sind ja beide Systeme verteilt bzw. getrennt.
Mit Client meinst du den ODBC Connector?
Client ist der, der per ODBC zugreift, also hier das Labwindows. Der braucht die Client-Software. Und der Host muß die Datenbank bereitstellen und die ODBC-Schnittstelle.
So wie Du es sagst, liegt beides auf dem selben Rechner?
Wenn ja, der wurde noch nicht aktualisiert. Das ist leider auch nicht so einfach. Ich will nicht auf gut Glück bei einem 24/7 System ein Update machen was wieder einen Rattenschwanz nach sich zieht (Updates aller beteiligten Programme). Das mache ich wenn ich mir sicher bin das es was bringt.
Da wirst Du vielleicht nicht drum herum kommen. Aktuell ist ja ODBC 5.3.4 (http://dev.mysql.com/downloads/connector/odbc/). Wenn Du sagst, daß es sonst ohne Probleme läuft, und alle paar Tage mal nicht, könnten das ein Speicherüberlauf, Programmfehler etc. im Treiber sein, was dann solche unsinnigen Fehlermeldungen wirft. Vielleicht verursacht ja Dein genanntes Programm diesen Fehler selbst.
Ich würde hier mal den ODBC-Treiber auf 5.3.4. aktualisieren, das geht meistens gefahrenlos. Trotzdem auf alle Fällen den alten Treiber beibehalten oder wegsichern. Man kann ja dann im ODBC-Menü einfach eine neue Datenquelle mit dem neuen Treiber anlegen.
Alternativ kann Du natürlich auch in den Release Notes erst mal aufwendig recherchieren, ob dieser Fehler in den Fehlermeldungen/Bugfixes auftaucht.
Schau Dir auf alle Fälle die Einstellungen der bisherigen ODBC-Verbindung an, und notiere sie bzw. mache Screenshots von den Einstellungen. Eventuelle Zugängen mit User/Kennwort für das korrekte Schema und Datenkbank sollten Dir natürlich bekannt sein, wenn nicht, unbedingt geben lassen.
FlashBurn
2014-11-25, 20:12:35
So wie Du es sagst, liegt beides auf dem selben Rechner?
In dem Fall schon.
Da wirst Du vielleicht nicht drum herum kommen. Aktuell ist ja ODBC 5.3.4 (http://dev.mysql.com/downloads/connector/odbc/). Wenn Du sagst, daß es sonst ohne Probleme läuft, und alle paar Tage mal nicht, könnten das ein Speicherüberlauf, Programmfehler etc. im Treiber sein, was dann solche unsinnigen Fehlermeldungen wirft. Vielleicht verursacht ja Dein genanntes Programm diesen Fehler selbst.
Das mein Programm den Fehler verursacht möchte ich nicht ausschließen, glaube ich aber nicht. Da ich einen Speicherüberlauf ausschließen kann, da das Programm seinen Speicher nur einmal am Anfang initialisiert und dann nichts mehr dynamisch passiert.
Alles was dynamisch passiert, ist in der Runtime oder dem ODBC Connector.
Ich würde hier mal den ODBC-Treiber auf 5.3.4. aktualisieren, das geht meistens gefahrenlos. Trotzdem auf alle Fällen den alten Treiber beibehalten oder wegsichern. Man kann ja dann im ODBC-Menü einfach eine neue Datenquelle mit dem neuen Treiber anlegen.
Beibehalten ist gut, bei dem Versuch auf meinem Rechner hat er die alte Version deinstalliert.
Alternativ kann Du natürlich auch in den Release Notes erst mal aufwendig recherchieren, ob dieser Fehler in den Fehlermeldungen/Bugfixes auftaucht.
Hab ich grob gemacht und auf die schnelle nix gefunden.
Schau Dir auf alle Fälle die Einstellungen der bisherigen ODBC-Verbindung an, und notiere sie bzw. mache Screenshots von den Einstellungen. Eventuelle Zugängen mit User/Kennwort für das korrekte Schema und Datenkbank sollten Dir natürlich bekannt sein, wenn nicht, unbedingt geben lassen.
User/Kennwort ist nicht das Problem. Problem ist eher das ich mir was einfallen lassen müsste wie ich das dynamisch in der Registry, von meinem Programm heraus, ändern kann. Weil es so einfacher für mich und den Kunden ist.
Ich werde also nicht drumherum kommen zu gucken welche ODBC-Connector Version auf dem System installiert ist bzw. welche neueste Version und eventuell die schon vorhandene auf die neue Version umzuschreiben.
Das ist zwar einmal zeitaufwendig, aber dann kann man immer ein Update machen und die Programme laufen weiterhin.
Beibehalten ist gut, bei dem Versuch auf meinem Rechner hat er die alte Version deinstalliert.
Wie wurde das den installiert? Wenn ich bei Kunden bin, landet alles, was ich installiere, versioniert in einem Ordner, so daß man stets alles wieder nachinstallieren kann, eben auch die älteren Versionen. Das der neue Treiber den alten weghaut, ist klar.
Und wieso mußt Du Dein Programm umschreiben, wenn Du nur den ODBC-Treiber wechselst? :confused:
FlashBurn
2014-11-26, 12:33:29
Und wieso mußt Du Dein Programm umschreiben, wenn Du nur den ODBC-Treiber wechselst? :confused:
Da die keinen Admin haben der sich um alles kümmert und wir (die Firma für die ich arbeite) das weder leisten können noch wollen, muss die ODBC-Verbindung, wenn nicht vorhanden, automatisch beim Programmstart erstellt werden.
Ist sie schon vorhanden muss sie auf den aktuell installierten ODBC-Treiber umgestellt werden usw.
Auch installiere ich nicht alles selber, sondern einige Sachen machen die auch selber. Deswegen muss es so einfach wie möglich sein und so sicher wie möglich.
Ach Du Sch.... :eek:
Ganz ehrlich, würde ich nicht machen. ODBC-Quellen würde ich immer von Hand angelegen und testen. Zur Not leg eine Anleitung mit bei. Aber so eine Verbindung auch per Registry zu patchen würde ich bleiben lassen.
Also mein DB-Admin-Kollege schluckt auch gerade mit dem, was Du vorhast.
FlashBurn
2014-11-26, 13:15:11
Tja, was soll ich machen, ist eine Forderung vom Kunde und du weißt ja wie es ist, der Kunde ist König und ich nur ein Angestellter ;)
Zumal das hier auch so gehandhabt wird, haben wir schon immer so gemacht und hat doch immer funktioniert ;)
Das mit der Anleitung ist auch nicht so einfach, weil 64bit OS, aber 32bit Treiber und Programm. Sprich du musst in den Tiefen des Windowssystems nach der richtigen Datei suchen, die noch als Admin ausführen und dann die Daten eintragen. Was da wieder alles schiefgehen kann ;)
So was regelt man eigentlich sauber im Betriebsübergang bzw. Service-Vertrag. Man kann es auch als Systemvoraussetzung deklarieren, und dann aber gerne den Service dafür anbieten. Und ich kenne bisher kein Programm oder Anwendung, welche sich selbst seine ODBC-Quellen anlegt, weil man das auch so nicht macht, Stichwort saubere Trennung Anwendung und Datenbank usw.
FlashBurn
2014-11-26, 13:33:55
So was regelt man eigentlich sauber im Betriebsübergang bzw. Service-Vertrag. Man kann es auch als Systemvoraussetzung deklarieren, und dann aber gerne den Service dafür anbieten. Und ich kenne bisher kein Programm oder Anwendung, welche sich selbst seine ODBC-Quellen anlegt, weil man das auch so nicht macht, Stichwort saubere Trennung Anwendung und Datenbank usw.
So dachte ich auch noch als ich frisch von der Uni kam. Jetzt hat mich das echte Leben eingeholt ;)
Ich sehe das mit der Trennung auch nicht so verbissen. Das Programm ist auf eine MySQL Datenbank angewiesen. Wenn es einfacher gewesen wäre, hätte ich lieber eine DLL genommen und über die auf die DB zugegriffen, aber so war ODBC die einfachste und vorallem schnellste Lösung.
Ich werde mal mit meinem Chef klären wie man dem Kunden am besten beibringt, dass er nicht alles auf uns abwälzen kann bzw. wenn dann kostet es extra (und da ist der Kunde dann empfindlich ;) ).
Ich mache schon über 20 Jahre IT mit Datenbanken und ODBC, und ich habe echt noch nicht erlebt, daß man das so macht. Klar ist das möglich, aber in der Praxis macht so was viel mehr Probleme als das es hilfreich ist.
Warum greift Ihr dann nicht gleich direkt nativ auf die Datenbank zu? Dann spart Ihr Euch doch den Umweg über ODBC? Das mit dem ODBC ist dann sinnvoll, wenn man die Sache verteilt, beispielsweise auf einen extra Server, der Datenbanken verwaltet. Wenn die Datenbank auch auf dem System liegt, würde ich gleich direkt per Libs usw. darauf zugreifen, und man spart sich die ODBC-Konfiguration.
Kostenmäßig kann ein nicht sauber gelöster Vertrag schnell nach hinten losgehen. Gerade Datenbanken würde ich immer in die Verantwortung des Kunden legen, und dann für den Service extra kassieren. Mach wir hier seit Jahren auch so, und es funktioniert gut.
FlashBurn
2014-11-26, 14:04:59
Warum greift Ihr dann nicht gleich direkt nativ auf die Datenbank zu? Dann spart Ihr Euch doch den Umweg über ODBC? Das mit dem ODBC ist dann sinnvoll, wenn man die Sache verteilt, beispielsweise auf einen extra Server, der Datenbanken verwaltet. Wenn die Datenbank auch auf dem System liegt, würde ich gleich direkt per Libs usw. darauf zugreifen, und man spart sich die ODBC-Konfiguration.
Naja, das System ist auch so geplant und umgesetzt gewesen, dass die DB auf einem extra Server läuft, aber das war dem Kunden ein PC zu viel ;)
So läuft die DB jetzt auf dem selben Rechner wie das Programm was die Werte erfässt.
Allerdings gibt es dann noch ein Programm, welches auf diesem PC und allen anderen PCs des Kunden läuft und auch auf die DB zugreift und wenn man dann einmal ODBC nutzt, nutzt man es immer. Zumal die CVI es so einfacher macht als wenn ich erst die DLL einbinden müsste.
Wäre das alles nur einmal einzurichten, würde ich auch sagen, hinfahren einmal einrichten und gut ist. Leider müsste das dann für jeden neuen Rechner wieder gemacht werden und jetzt weiß der Kunde schon das es auch automatisch geht. Chance verspielt ;)
Kostenmäßig kann ein nicht sauber gelöster Vertrag schnell nach hinten losgehen. Gerade Datenbanken würde ich immer in die Verantwortung des Kunden legen, und dann für den Service extra kassieren. Mach wir hier seit Jahren auch so, und es funktioniert gut.
Die DB liegt auch in der Verantwortung des Kunden, laut Vertrag, aber erzähl das mal meinem Chef. Wie gesagt Kunde ist König. Bzw. ist der Kunde der Meinung dass das Einrichtung der ODBC Verbindung automatisch gehen muss und in unserem Verantwortungsbereich liegt.
Wäre das alles nur einmal einzurichten, würde ich auch sagen, hinfahren einmal einrichten und gut ist. Leider müsste das dann für jeden neuen Rechner wieder gemacht werden und jetzt weiß der Kunde schon das es auch automatisch geht. Chance verspielt ;)
Teamviewer/RDP über VPN?
Die DB liegt auch in der Verantwortung des Kunden, laut Vertrag, aber erzähl das mal meinem Chef. Wie gesagt Kunde ist König. Bzw. ist der Kunde der Meinung dass das Einrichtung der ODBC Verbindung automatisch gehen muss und in unserem Verantwortungsbereich liegt.
Na, da liegen beide sowas von falsch. ;) Was ist den, wenn der Kunde die Datenbank wechselt, oder die Version, andere Datenbank bzw. Tablespaces usw.? Das ist definitiv keine automatische Konfiguration. So mußt Du jedes Mal Dein Programm anpassen, wenn sich irgend etwas hier ändert. Und genau deshalb wurde doch die ODBC-Schnittstelle geschaffen, um das zu trennen. Der Sinn ist doch, daß Du jederzeit mit Deinem Programm auf beliebige Datenbanken per ODBC zugreifen kannst, ohne im Programm bzw. in der Anwendung etwas zu ändern.
Mit Eurer Logik hebelt Ihr diesen nützlichen Mechanismus der Flexibilität vollkommen aus! Ich halte das - unabhängig jetzt von Dir und ohne Dich beleidigen zu wollen - für absolut dumm. Ich würde das dem Kunden und Deinen Chef ausreden. Ansonsten muß man das wirklich dem Kunden kräftig in Rechnung stellen, damit sich das für Euren Betrieb auch kostenmäßig lohnt. Wahrscheinlich kann Dein Chef hier nicht richtig kalkulieren, weil Ihr müßt das als Wartungs- /Aufwandskosten unbedingt entsprechend mit einberechnen. Sonst legt Dein Chef hier drauf.
FlashBurn
2014-11-26, 15:06:44
Teamviewer/RDP über VPN?
Der war gut, ich darf ja nicht mal vor Ort in deren Netzwerk und dazu müsste ja auf deren Seite ein Admin vorhanden sein, der alles so einrichtet (VPN und Co).
Na, da liegen beide sowas von falsch. ;) Was ist den, wenn der Kunde die Datenbank wechselt, oder die Version, andere Datenbank bzw. Tablespaces usw.? Das ist definitiv keine automatische Konfiguration. So mußt Du jedes Mal Dein Programm anpassen, wenn sich irgend etwas hier ändert. Und genau deshalb wurde doch die ODBC-Schnittstelle geschaffen, um das zu trennen. Der Sinn ist doch, daß Du jederzeit mit Deinem Programm auf beliebige Datenbanken per ODBC zugreifen kannst, ohne im Programm bzw. in der Anwendung etwas zu ändern.
Also der Kunde wird die DB nie wechseln, weil er gar keine Ahnung von DBs hat und den Aufbau der Tabellen nicht kennt.
Die Flexibilität gilt doch auch nur für ODBC. Korrigiere mich wenn ich falsch liege, aber soweit ich es gefunden habe ist schon das Überprüfen ob eine Tabelle vorhanden ist auf jedem DBMS spezifisch und muss mit anderen SQL Anweisungen gemacht werden.
Ja Tabellen werden auch dynamisch angelegt, wenn sie nicht vorhanden sind.
Mit Eurer Logik hebelt Ihr diesen nützlichen Mechanismus der Flexibilität vollkommen aus! Ich halte das - unabhängig jetzt von Dir und ohne Dich beleidigen zu wollen - für absolut dumm. Ich würde das dem Kunden und Deinen Chef ausreden.
Weder dem einen noch dem Anderen ist das auszureden und das Kind ist eh schon in den Brunnen gefallen. Das System läuft ja schon 24/7. Nur gibt es halt noch dieses eine nervige Problem. Da die Funktion, welche das Problem hervorruft, nur selten bis gar nicht aufgerufen wird, wurde es bisher halt so hingenommen.
Versteh ich, wollts nur mal gesagt haben. ;)
Hast Du jetzt mal den Treiber ausgewechselt?
FlashBurn
2014-11-26, 18:52:23
Nope, ich wollte das bei mir erst noch ausgiebig testen. Bei nem 24/7 System was soweit läuft bin ich eher vorsichtig. Vorallem kurz vorm Urlaub ;)
Und wie sichert Ihr das Ding. Was ist Euer Fallbackszenario hier? Wenn das Ding 24/7 läuft, und permanent in die Datenbank geschrieben wird, kann diese nicht korrekt gesichert werden usw.
FlashBurn
2014-11-27, 08:06:14
Erinner mich nicht an die Sicherung ;)
Wir haben dem Kunden gesagt das es in seinem Verantwortungsbereich liegt sich um die Sicherung zu kümmern. Eigentlich sollte das System auf einem RAID 1 laufen und die DB sollte alle Sachen an eine zweite DB auf einem anderen Server weiterschicken und dieser Server wird dann täglich gesichert.
Umgesetzt wurde weder das RAID 1 noch der zweite Server. Von daher ;)
Solche Kunden verdienen einfach einen Headcrash.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.