Extreme Veteran
Beiträge: 563
 
| Hallo,
SvenG - 09.12.16 11:28
und ja, es war reproduzierbar. ich habe die formularquelle dann manuell auf den betreffenden "select *" befehl gesetzt und in der produktivversion der db kam dann ein odbc-error. in der test oder entwicklerversion (identische datenbankstruktur, nur andere/weniger daten) kam der fehler nicht.
Es kann auch an den Daten selbst liegen. Ich kämpfe andernorts gerade mit so einem Problem. Tritt es auch auf, wenn du auf beiden Rechnern identische Daten ziehst?
naja, ich hab ja eine lösung gefunden und es läuft: statt dem "*" einfach alle felder aufzählen obwohl extrem nervig bei großen tabellen.
Lästig vielleicht (ich geh davon aus, dass du dir das Statement in SSMS hast scripten lassen, oder?), aber robuster. Jetzt hast du aber die Möglichkeit, durch schrittweises Hinzufügen der ungenutzten Felder das "böse" rauszufinden, wenn man unterstellt, dass der * ursächlich für das Problem ist.
ich glaube einfach, das access-datenbanken manchmal einfach "kaputtgehen" d.h.nicht komplett aber an einer stelle im code, so das dieser teil dann nicht mehr richtig läuft. diese theorie kommt übrigens nicht von ungefähr: ich habe eine andere access-db die ca. 20 mitarbeiter in unserer abteilung nutzen (jeder eine kopie auf seinem c-laufwerk, die tabellen liegen auf einem sql server). bei 1-2 nutzern passiert es regelmäßig, das dessen access-db´s nach ca.3 monaten beim start anfangen einen fehler zu melden der vorher nie kam. wenn ich dann die ursprüngliche access-db dem user wieder in sein benutzerverzeichniss kopiere, geht es wieder einige zeit...
Das ist leider so, weshalb es die Onboard-Funktionen Compact/Repair und /Decompile gibt.
-----
Gruss - Peter |
