Access hangup, mysql linked tables über myODBC3.51

Computer: Software & Programmierung Microsoft Access
#1

hallo an alle experten,

meine HW:
Pentium 4 >2000 Mhz Intel Celeron
Platte 80 GB ~7200 rpm
512 RAM

meine SW:
Win XP unter VMWare ( Virtuelle Platte insg. 4GB, frei ~2GB, Virt. RAM ~256 )
auf dem neuesten Stand, weil MS update via I-net
VMWare aufgesetzt auf GNU/Linux
Kernel version 2.4.20-4GB

linux:
windowmaker, mysql php blabla, also laufender X

WinXP:
Office 97 (Access 97), MyOdbc3.5, MySql, Microsoft Data Access Components (MDAC) 2.8

ACCESS:
geupdated via ms-hp

Situation:
mysql laeuft, zugriff erfolgreich, auch via MyODBC. anfragen werden innerhalb weniger msek. realisiert, jedenfalls via winxp client.

Access:
via MyODBCV-schnittstelle gelinkte tabellen.
Schnittstelle funktioniert, anfagen sind erfolgreich. ueber die gelinkten tabellen kann ich auf die inhalte in den tabellen zugreifen.

Problem:
Es existierten auf der alten Access DB, die ich nach MySQL portiert habe, bereits Formulare fuer das einfuegen und das anzeigen von Informationen.

Ich habe mich bisher nur daran gewagt, die daten via Formular abzufragen.

Ergebnis:
Access hat staendig einen hangup. Nachdem ich mich darueber gewundert haeb darueber, und einmal die logdatei von mysql betrachtete (via befehl tail in linux), habe ich

1. gesehen dass voellig unsinnige anfragen produziert werden, wie z.B.:

SELECT tbl_CheckSheet.CheckSheet_ID FROM tbl_checksheet tbl_CheckSheet WHERE (CheckSheet_ID = 8 )

dabei ist checksheet_id eindeutig. derartige abfragen gibt es in access nicht.

2. die Anfragen, die nach mysqld.log gehen kommen dort z.T. im Minutentakt an! Nachdem ich vermutet habe, dass die zeitliche Verzoegerung bei mysql liegt, obwohl ich es besser haette wissen muessen, habe ich die selects die dort stattfinden ueberprueft.
Die Anfrage werden hangup).

hm, ich weiss, die MS begeisterten unter euch werden das nicht gerne hoeren:

absolut bescheuert, dass access nicht mal debugging infos raushaut, wo der absturz passiert. die MyODBC logs sind fuer mich absolut unlesbar. Gibtb es denn nicht eine moeglichkeit mehr ueber den Absturz herauszufinden, als diese dumme von MS produzierten Fehlernummern?

Ja, ich bin erst einmal mit meinem Latein am ende. kann mir jemand helfen?

tja, und waehrend ich das hier schreibe, haengt sich dass ding zum x. ten mal auf.

szAppName : msaccess.exe szAppVer : 8.0.0.5903 szModName : hungapp
szModVer : 0.0.0.0 offset : 00000000
;o)

super fehler bericht, voll gut!!! ;o)

wenn hier keiner rat weiss, kann mir vielleicht jemad einen tip geben, wo man rat her bekommt?

thx im voraus

  • josh -
#2

die Sachen beachtet?

http://dev.mysql.com/doc/connector/odbc/en/faq_4.html

denke mal ja, wenn du im Netz schon gesucht hast.

1. gesehen dass voellig unsinnige anfragen produziert
werden, wie z.B.:

SELECT tbl_CheckSheet.CheckSheet_ID FROM tbl_checksheet
tbl_CheckSheet WHERE (CheckSheet_ID = 8 )

dabei ist checksheet_id eindeutig. derartige abfragen gibt es
in access nicht.

Diese Abfragen kommen vom ODBC Treiber, dort zu tracken ist nicht sinnvoll. (Ausser du willst wissen wie der ODBC Treiber die Queries übersetzt)

absolut bescheuert, dass access nicht mal debugging infos
raushaut, wo der absturz passiert. die MyODBC logs sind fuer
mich absolut unlesbar. Gibtb es denn nicht eine moeglichkeit
mehr ueber den Absturz herauszufinden, als diese dumme von MS
produzierten Fehlernummern?

Das sind Windows debug Infos - Access hatte sich schon verabschiedet und konnte keine Fehlermeldung mehr geben. Wenn Access sich so verabschiedet liegt das Problem tiefer - will heissen mehr in Verbindung mit dem OBBC Treiber.

Davon abgesehen, halte ich es für besser, wenn du eine neuere Access-Version nimmst. Access97 ist was ODBC betrifft ziemlich buggy. Gut läuft die m.E. nur mit einer MS-SQL7 DB. Aber selbst mit einer MS-SQL2000 hatte ich schon Probleme.

Ich habe eine Anwendung bei einem Kunden am laufen mit AccessXP und mySQL. Rasend schnell und ohne Probleme. Es geht also …

Gruss
Quaser

#3

hi Quaser,

erst einmal vielen dank fuer die schnelle Antwort.

die Sachen beachtet?

http://dev.mysql.com/doc/connector/odbc/en/faq_4.html

denke mal ja, wenn du im Netz schon gesucht hast.

ja, war die seite die ich als Anleitung benutzt habe, um meine Tabellen zu linken.

1. gesehen dass voellig unsinnige anfragen produziert
werden, wie z.B.:

SELECT tbl_CheckSheet.CheckSheet_ID FROM tbl_checksheet
tbl_CheckSheet WHERE (CheckSheet_ID = 8 )

dabei ist checksheet_id eindeutig. derartige abfragen gibt es
in access nicht.

Diese Abfragen kommen vom ODBC Treiber, dort zu tracken ist
nicht sinnvoll. (Ausser du willst wissen wie der ODBC Treiber
die Queries übersetzt)

absolut bescheuert, dass access nicht mal debugging infos
raushaut, wo der absturz passiert. die MyODBC logs sind fuer
mich absolut unlesbar. Gibtb es denn nicht eine moeglichkeit
mehr ueber den Absturz herauszufinden, als diese dumme von MS
produzierten Fehlernummern?

Das sind Windows debug Infos - Access hatte sich schon
verabschiedet und konnte keine Fehlermeldung mehr geben. Wenn
Access sich so verabschiedet liegt das Problem tiefer - will
heissen mehr in Verbindung mit dem OBBC Treiber.

kann es also nicht sein, dass der fehler beim Formular liegt. will meinen, dass der crash dadurch verursacht wird, dass die von ODBC an Access zurueckgegebenen datentypen nicht kompatibel sind. Mein erstes Problem lag darin, dass Access die Daten immer mit dem #deleted# angezeigt hatte. dass konnte ich dann beseitigen.
koennten weitere derartige Fehler im zusammenhang mit dem unterschiedlichen Datenhandling entstehen? ich habe hier eine kompatibiltaetsliste vor mir liegen accessmysql, allerdings frage ich mich dann, warum ich ueber die ansicht die daten korrekt angezeigt bekomme. soweit ich weiss liegen da vba scripts hinter diesen formularen. vielleicht sind die ja ein wenig uebersensibel.

Davon abgesehen, halte ich es für besser, wenn du eine neuere
Access-Version nimmst. Access97 ist was ODBC betrifft ziemlich
buggy. Gut läuft die m.E. nur mit einer MS-SQL7 DB. Aber
selbst mit einer MS-SQL2000 hatte ich schon Probleme.

hmm, ja. naja, das problem liegt darin, dass es schon gut waere das ganze fuer access97 zu machen. denn die clients laufen bisher alle mit access 97 und es soll ein nahtloser uebergang geschaffen werden. allerdings ist das natuerlich auch eine machbarkeitssache. vielleicht muss ich doch auf ein frischeres access zurueckgreifen. ist zu ueberlegen.

Ich habe eine Anwendung bei einem Kunden am laufen mit
AccessXP und mySQL. Rasend schnell und ohne Probleme. Es geht
also …

naja, das macht mir auf jeden fall hoffnung. ich bastel jeztt noch ein wenig rum, mal schauen was rum kommt.

die sache mit dem vba waere natuerlich noch schoen, wenn beantwortet waere. allerdings, ist es auch absoluterbloedsinn jetzt alle vba’s neu anzupassen. der aufwand ist uz gross.

Gruss
Quaser

schoenes wochenende

  • josh -
#4

kann es also nicht sein, dass der fehler beim Formular liegt.
will meinen, dass der crash dadurch verursacht wird, dass die
von ODBC an Access zurueckgegebenen datentypen nicht
kompatibel sind. Mein erstes Problem lag darin, dass Access
die Daten immer mit dem #deleted# angezeigt hatte. dass konnte
ich dann beseitigen.

übrigens, wenn Access des öfteren so hart abgeschmiert ist, dann solltest du deiner eigenen mdb nicht mehr trauen. Auch reparieren und komprimieren holt nicht immer alle Fehler raus. Da hilft nur neue mdb erstellen und die objekte (Queries, Forms usw) aus der alten mdb importieren.

Gruss
Quaser

#5

das Workaround zu meinem Problem:

anstatt winxp mit win 2000 arbeiten.
winxp myodbc und access97 ist nicht gut.

bis dann und vielen dank an alle

  • josh -