none
Berichtsabbruch mit unsinnigen Fehlermeldungen in Access 2003, Laufzeitfehler ’-2147417848 (80010108)’

    Frage

  • Hallo liebe Mitstreiter,

    seit einigen Jahren schon bewegt mich folgendes Problem in Access 2003: Berichte brechen ab einem bestimmten Umfang mit unsinnigen Fehlermeldungen ab bzw. melden sich auch gar nicht wieder zurück. Bisher dachte ich immer, dass Access 2003 einfach nur überfordert ist  und habe eben jedes Mal zähneknirschend versucht, das Problem irgendwie zu umgehen. Nun habe ich vor ein paar Wochen die Entwicklung und damit natürlich auch den Programmtest  auf Access 2010 verlegt. Und siehe da, es funktioniert: Berichte, die unter 2003 nach spätestens 400 Seiten zu den nachfolgend genannten Fehlern führen, laufen unter Access 2010 auch mit 1800 Seiten ohne Abbruch durch. Da ich dieses Verhalten als Bestätigung meiner Annahme von der Access 2003-Überforderung betrachte, könnte ich damit ja zufrieden sein.

    Allerdings arbeitet der überwiegende Teil meiner Anwender unter Access 2003 und wird in naher Zukunft auch gar nicht umstellen (wollen). Also bin ich nicht zufrieden und will es nun wissen!

    Der (bzw. die) Fehler tritt (treten) auf unter Access 2003 und zwar immer dann, wenn ein Bericht, der einen großen Seitenumfang hat (nachvollziehbar immer oberhalb von 400 Seiten, aber auch schon ab 190 Seiten bei mehr als 400 (bspw. 435) Datensätzen o.ä.), formatiert wird. Ich bin mir nicht ganz, aber ziemlich sicher, dass der Fehler tatsächlich beim Formatieren des Berichts auftritt und nicht schon bei der Abfrage.

    Sehr häufig habe ich Fehler wie

    Laufzeitfehler ’-2147417848 (80010108)’:

    Die Methode ’Left’ für das Objekt ’_Textbox’ ist fehlgeschlagen.

    oder

    Laufzeitfehler ’-2147417848 (80010108)’:

    Die Methode ’Width’ für das Objekt ’_Textbox’ ist fehlgeschlagen.

    Nun könnte man ja meinen, die Fehler ergeben sich, weil den Eigenschaften Left oder Width unerlaubt (negative, niedrige oder hohe) Werte zugewiesen werden sollen. Dies hatte ich aber X-mal geprüft. Dem ist nicht so. Abgesehen davon, würde dies dann vermutlich auch zu ganz anderen Fehlern führen.

    Einen Sinn könnte da eher schon die folgende Fehlermeldung geben:

    Laufzeitfehler ’2101’:

    Die von Ihnen eingegebene Einstellung ist für diese Eigenschaft nicht zulässig.

    Aber auch das hatte ich mit Sicherheit (vermutlich!!) geprüft. Andere, ebenfalls aufgetretene, Fehler hier aufzuführen, spare ich mir im Moment.

    Bei den Tests hatte ich immer wieder nur neu feststellen müssen, dass die überprüften Werte schlüssig waren und den Fehler hätten nicht herbeiführen können/dürfen und die Fehlermeldung letztlich in keinem Zusammenhang mit dem Abbruch standen, weshalb ich mir schließlich mit der Überforderungsmeinung einen Grund zurecht gelegt habe, um immer wieder neue Tests zu vermeiden. Und irgendwie gibt dem ja auch Recht, dass dieselben Berichte unter Access 2010 fehlerfrei laufen.

    Das hilft aber den Anwendern unter Access 2003 nicht.

    Deshalb meine Frage: Kann dieses Verhalten jemand bestätigen und möglicherweise eine Lösung anbieten, die erst einmal nicht Access 2010 o.ä. heißt?

    Mit freundlichen Grüßen


    Werner Muehlmann

    Freitag, 15. Juni 2012 13:11

Antworten

  • Hallo Robert,

    danke für den Hinweis. Ich meine aber schon, dass ich hilfreiche u.ä. Beiträge bestätige. Allerdings meine ich auch, deutlich gemacht zu haben, dass mich in dieser Angelegenheit bisher keine Resonanz ergriffen hat und ich deshalb alles noch "gären lassen" will. Insofern kann ich also keinen Beitrag bewerten, sondern lediglich antworten. Und die Antwort entspricht dieser Feststellung: Ich lasse alles wie es ist, greife also keinen Hinweis auf. Da die Angelegenheit in Access 2010 ohnehin geklärt ist und das Problem tatsächlich in Access 2010 nicht mehr auftritt und wir auch schon knapp 10 Jahre nach Access 2003 haben, meine ich, meine Kunden auf Access 2010 verweisen zu können. Für wenig aufwändige Hinweise bin ich aber weiter empfänglich. Deshalb habe ich diese Angelegenheit nicht abgeschlossen. Ich meinte, deshalb nichts weiter unternehmen zu müssen. War das falsch?

    Beste Grüße


    Werner Muehlmann

    Mittwoch, 18. Juli 2012 15:41

Alle Antworten

  • WerMily wrote:
    > ...
    > Der (bzw. die) Fehler tritt (treten) auf unter Access 2003 und zwar
    > immer dann, wenn ein Bericht, der einen großen Seitenumfang hat
    > (nachvollziehbar immer oberhalb von 400 Seiten, aber auch schon ab
    > 190 Seiten bei mehr als 400 (bspw. 435) Datensätzen
    > ...
    > Deshalb meine Frage: Kann dieses Verhalten jemand bestätigen und
    > möglicherweise eine Lösung anbieten,
    > ...
     
    Veranstaltest du viel an Programmierung im Bericht oder geht
    es nur um umfangreiche Datensatzherkünfte?
     
    Ich habe nie so "vielseitige" Berichte, aber bei einigen
    Berichtsüberforderungen (Datenmenge, Performance, Speicher)
    hilft es oft, statt einer Abfrage als Datenherkunft eine temporäre
    Tabelle zu verwenden, die vorher eben mit den Abfragedaten
    gefüllt wird. Wenn du das noch nicht getestet hast, wäre es
    einen Versuch wert.
     
    --
    Servus
    Karl
    *********
     
     
     
    Freitag, 15. Juni 2012 21:06
  • Am 15.06.2012 schrieb WerMily:

    seit einigen Jahren schon bewegt mich folgendes Problem in Access 2003: Berichte brechen ab einem bestimmten Umfang mit unsinnigen Fehlermeldungen ab bzw. melden sich auch gar nicht wieder zurück. Bisher dachte ich immer, dass Access 2003 einfach nur überfordert ist  und habe eben jedes Mal zähneknirschend versucht, das Problem irgendwie zu umgehen. Nun habe ich vor ein paar Wochen die Entwicklung und damit natürlich auch den Programmtest auf Access 2010 verlegt. Und siehe da, es funktioniert: Berichte, die unter 2003 nach spätestens 400 Seiten zu den nachfolgend genannten Fehlern führen, laufen unter Access 2010 auch mit 1800 Seiten ohne Abbruch durch. Da ich dieses Verhalten als Bestätigung meiner Annahme von der Access 2003-Überforderung betrachte, könnte ich damit ja zufrieden sein.

    Ist denn der Hotfix nach dem SP3 für A2003 auch installiert?
    http://support.microsoft.com/kb/945674

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Samstag, 16. Juni 2012 23:10
  • Hallo Werner

    Werner Mühlmann wrote:

    Allerdings arbeitet der überwiegende Teil meiner Anwender unter Access
    2003 und wird in naher Zukunft auch gar nicht umstellen (wollen). Also
    bin ich nicht zufrieden und will es nun wissen!

    Der (bzw. die) Fehler tritt (treten) auf unter Access 2003 und zwar immer
    dann, wenn ein Bericht, der einen großen Seitenumfang hat
    (nachvollziehbar immer oberhalb von 400 Seiten, aber auch schon ab 190
    Seiten bei mehr als 400 (bspw. 435) Datensätzen o.ä.), formatiert wird.
    Ich bin mir nicht ganz, aber ziemlich sicher, dass der Fehler tatsächlich
    beim Formatieren des Berichts auftritt und nicht schon bei der Abfrage.

    Die Anzahl Seiten für Access Berichte ist nicht limitiert (über Access). Die Limitation kommt allerdings vom System. Wenn diesem die Ressourcen ausgehen (und wieso diese ausgehen konnte bisher noch niemand so genau erläutern), dann kommt es zu merkwürdigem Verhalten bei Berichten (und nicht nur da).

    Abhilfe - wie Karl bereits geschrieben hat - ist meist die Verwendung von temporären Tabellen, die die komplette Bereichtsdatenquelle beinhalten. Optimalerweise legst Du diese sogar in eine temporäre Datenbank und linkst diese von dort, damit es Dir die Anwendung nicht aufbläht. Beachte, dass Du dort z.B. auch Felder, die Du mit einem DLookup() einliest, bereits aufgelöst ablegen solltest, sonst hast Du bald wieder ein Ressourcen Problem.

    Eine Alternative ist, den Bericht stückchenweise auszudrucken, also z.B. in 100 Seiten Portionen.

    Gruss
    Henry

    Montag, 18. Juni 2012 05:59
  • Hallo Karl, hallo Winfried, hallo Henry,

    zunächst erst einmal vielen Dank für Eure Reaktionen.

    Ich denke, wir sind uns erst einmal einig, dass wir uns solche Berichte nicht in den Schrank stellen würden. Aber Ihr wisst ja, woran man immer noch nach einer Sintflut erkennt, wo vorher Deutschlang gelegen hat.... Es gibt eben Branchen, die gern selbst solche Berichte im Schrank stehen haben, und Branchen, die andere nötigen, sich solche in den Schrank zu stellen. Überall wo gegebenfalls die Staatsanwaltschaft o.ä. Behörden vorstellig werden könnten, hat man gern ein solches Polster. Soweit zur Vorgeschichte.

    Ich bin bisher kein großer Freund von temporären Tabellen gewesen und habe immer versucht, diese zu vermeiden. Aber möglicherweise werde ich wohl doch nicht herum kommen. Ich denke, das Hotfix wird mir nicht weiter helfen, würde mich aber nochmals melden, sollte ich gegenteilige Erfahrungen machen.

    Insofern also nochmals vielen Dank.


    Werner Muehlmann

    Montag, 18. Juni 2012 10:37
  • Werner Mühlmann wrote:
    > ...
    > Ich bin bisher kein großer Freund von temporären Tabellen gewesen
    > und habe immer versucht, diese zu vermeiden.
    > ...
     
    Ich hingegen bin ein großer Fan, weil man damit in vielen Situationen
    performanter und kontrollierter agieren kann. Mit "temporär" meinte
    ich hier übrigens permanent vorhandene "Arbeitstabellen".
    Temporär sind nur die Daten, die jedesmal gelöscht und neu
    hineingeladen werden.
     
    --
    Servus
    Karl
    *********
     
     
     
    Montag, 18. Juni 2012 16:19
  • Nochmals danke, Karl.

    Wie gesagt, Freund bin ich nicht. Aber ich gewinne dem Gedanken in diesem (Berichts-) Fall, insbesondere an temporäre Tabellen in externen, lokalen Datenbankdateien, zunehmend eine freundliche Seite ab, je mehr ich drüber nachdenke. Oder ich falle langsam auf die Hoffnung nach dem Strohhalm zurück.

    Also werde ich vermutlich genau das tun.

    Dennoch will ich ganz kurz die Gründe zu meiner Abneigung zusammentragen. Vielleicht kann ich dabei eine freundliche Seite mehr erkennen.

    In den neunziger Jahren habe ich überschwänglich mit permanent vorhandenen, temporären Tabellen in permanent vorhandenen externen, lokalen Datenbankdateien, die nur diese temporären Tabellen enthielten, gearbeitet. In Warenwirtschaftssystemen gab es während der Belegerfassung gleich mehrere temporäre Tabellen für  jede Belegart: Belegkopf, Kalkulationen, Belegpositionen, Seriennummern, Lager u.a.

    Ich war davon abgekommen, weil ich aus den verschiedensten Gründen eine Abneigung gegen mehrfach vorhandene Daten habe. Und bei der Ausgabe von Berichten müssen die in den temporären Dateien gesammelten Daten ja dennoch nach den gewünschten Strukturierungen gruppiert und der Bericht muss formatiert werden. Das heist, dass der Aufwand, der bei der Berichtsformatierung möglicherweise zum Abbruch geführt hatte, ja weitestgehend bestehen bleibt, weshalb vermutlich der Bericht auch nach der aufwändigen Programmänderung abbrechen würde. ... was eigentlich meinen Widerwillen, gegen eine solche Lösung, noch verstärkt...

    Und jetzt handelt es sich eben nicht um einen Warenwirtschaftssystem mit ein paar Seiten langen Ausgaben.

    Ich lass es also noch etwas gären.

    Mit bestem Gruß


    Werner Muehlmann

    Mittwoch, 20. Juni 2012 05:10
  • Hallo, Werner!
     
    Werner Mühlmann wrote:
    > ...
    > In den neunziger Jahren habe ich überschwänglich mit permanent
    > vorhandenen, temporären Tabellen in permanent vorhandenen
    > externen, lokalen Datenbankdateien, die nur diese temporären
    > Tabellen enthielten, gearbeitet. In Warenwirtschaftssystemen gab es
    > während der Belegerfassung gleich mehrere temporäre Tabellen für
    > ...
     
    Belegerfassung, also im Zshg. mit Dateneingaben, klingt gefährlich.
    So exzessiv betreibe ich das nicht, sondern gezielt. Zum einen in
    (Access/JET-)Problemfällen. Die gibt's allerdings in vielen
    Anwendungen an ein paar Stellen, z.B. inakzeptable Performance,
    Aufhänger, Nicht-Aktualisierbarkeit mit JET.
     
    Das zweite Anwendungsgebiet sind Aufbereitungen von Daten,
    die direkt mit den Grunddaten nicht oder nur zu mühsam möglich
    sind, z.B. Zeitpläne, Inhaltsverzeichnisse, Aufbereitung von
    Importdaten.
     
    Ein drittes Anwendungsgebiet sind allerlei Hilfstabellen bei
    Datensäuberungsaktionen. Das sind aber Sonderfälle.
     
    Im Regelbetrieb meiner Anwendungen gibt's meist eine handvoll
    solcher Arbeitstabellen. Kleine immer direkt im FE, denn FEs
    sind billig und fliegen eh bei jedem Update raus, (datenmäßig)
    große in permanenten Backends.
     
    > Ich war davon abgekommen, weil ich aus den verschiedensten
    > Gründen eine Abneigung gegen mehrfach vorhandene Daten habe.
     
    Das ist bei Berichtsdaten wenig tragisch.
     
    > Und bei der
    > Ausgabe von Berichten müssen die in den temporären Dateien
    > gesammelten Daten ja dennoch nach den gewünschten
    > Strukturierungen gruppiert und der Bericht muss formatiert werden.
     
    Joo, und beides geht mit einer Tabelle als Datenherkunft manchmal
    x-fach schneller als mit Abfragen. Berichte arbeiten mit eigenen
    ad-hoc generierten Recordsets, die sie zur Formatierung etc.
    verwurschten. Irgendwo bei der Übernahme aus der Datenherkunft
    in diese Berichts-RS gibt's mit langsamen/aufwändigen Abfragen
    gerne Probleme.
     
    > Das heist, dass
    > der Aufwand, der bei der Berichtsformatierung möglicherweise zum
    > Abbruch geführt hatte, ja weitestgehend bestehen bleibt, weshalb
    > vermutlich der Bericht auch nach der aufwändigen Programmänderung
    > abbrechen würde. ... was eigentlich meinen Widerwillen, gegen eine
    > solche Lösung, noch verstärkt...
    >
     
    Das kannst nur du entscheiden und ggf. testen.
    Die gelieferten Informationen über die Berichte reichen nicht aus,
    um mehr als den generellen Hinweis zu geben.
     
    --
    Servus
    Karl
    *********
     
     
    Mittwoch, 20. Juni 2012 09:43
  • Hallo Werner Mühlmann,

    Ich möchte Dich bitte folgendes lesen und die Beiträge die Dir geholfen haben zu bewerten. Vielen Dank.

    Nutzen Sie die Bewertungsfunktionen ("Antwort" und "Hilfreich") in den MSDN Foren! Unter anderem können andere später eine Lösung schneller finden. Es ist also wünschenswert, dass die fragenden (Benutzer) die Postings anderer Beantworter bewerten.
    Hier dazu die wichtigsten Anhaltspunkte aus den
    Forenregeln und FAQs.

    Lösungsbeiträge als „Die Antwort“ markieren
    Bitte markieren Sie den Beitrag, der zur Lösung geführt hat, als "Die Antwort". Durch Bewerten eines Beitrags als "Die Antwort" können andere Teilnehmer die Lösung schneller finden. Außerdem können Sie dem Benutzer, der die Antwort eingereicht hat, für seinen Beitrag danken und zur Steigerung der Antwortqualität in der Diskussionsgruppe beitragen.
    [Quelle:
    Forenregeln]

    Bitte markiere den/die Beiträge als Antwort, die dir geholfen haben, dein Problem zu lösen. Das ist zum einen eine Anerkennung für die Autoren dieser Beiträge, zum anderen hilft es zukünftigen Lesern, sich in diesem Thread besser zu orientieren und Antworten auf ihre Fragen schneller zu identifizieren.

    Wie zeige ich an, dass meine Frage durch einen Beitrag beantwortet wurde?

    Wie bewerte ich einen Beitrag als hilreich? Um einen Beitrag als hilfreich zu bewerten, klicken Sie in einem beliebigen Beitrag auf Als hilfreich bewerten. Sie können Ihre Stimme nur einmal für einen Beitrag abgeben.
    [Quelle:
    Häufig gestellte Fragen]

    Grüße,

    Robert


    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip„Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Mittwoch, 27. Juni 2012 09:51
    Besitzer
  • ****************************************************************************************************************
    Dieser Thread wurde mangels weiterer Beteiligung des Fragestellenden ohne bestätigte Lösung abgeschlossen.
    Neue Rückfragen oder Ergänzungen zu diesem Thread bleiben weiterhin möglich.
    ****************************************************************************************************************

    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Mittwoch, 18. Juli 2012 09:24
    Besitzer
  • Hallo Robert,

    danke für den Hinweis. Ich meine aber schon, dass ich hilfreiche u.ä. Beiträge bestätige. Allerdings meine ich auch, deutlich gemacht zu haben, dass mich in dieser Angelegenheit bisher keine Resonanz ergriffen hat und ich deshalb alles noch "gären lassen" will. Insofern kann ich also keinen Beitrag bewerten, sondern lediglich antworten. Und die Antwort entspricht dieser Feststellung: Ich lasse alles wie es ist, greife also keinen Hinweis auf. Da die Angelegenheit in Access 2010 ohnehin geklärt ist und das Problem tatsächlich in Access 2010 nicht mehr auftritt und wir auch schon knapp 10 Jahre nach Access 2003 haben, meine ich, meine Kunden auf Access 2010 verweisen zu können. Für wenig aufwändige Hinweise bin ich aber weiter empfänglich. Deshalb habe ich diese Angelegenheit nicht abgeschlossen. Ich meinte, deshalb nichts weiter unternehmen zu müssen. War das falsch?

    Beste Grüße


    Werner Muehlmann

    Mittwoch, 18. Juli 2012 15:41
  • War das falsch?

    Hallo Werner Mühlmann,

    Vielen Dank für Deine Rückmeldung.

    Nein war nicht falsch. Du hast es gut gemacht, ich dachte nur dass Du nicht mehr zurückkommst.

    Ich markiere dann Deine Antwort aber neue Rückfragen oder Ergänzungen zu diesem Thread bleiben weiterhin möglich für alle die noch dazu etwas sagen möchten.

    Grüße,

    Robert


    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Mittwoch, 18. Juli 2012 16:10
    Besitzer