none
Laufzeitfehler 3011 bei Zugriff auf WSS

    Frage

  • Hallo zusammen,

    ich habe eine Access-Lösung zusammengebaut, die auf Sharepoint-Listen zugreift. Die Listen sind über Importieren -> Sharepoint-Liste eingebunden. Der Zugriff erfolgt über DAO und dem folgenden Code:

    Dim qry_new As dao.QueryDef
    Set qry_new = currentdb().Database.CreateQueryDef("")
    qry_new.SQL = qrySQL 'Hier wird ein gültiges SQL-statement eingefügt
    Set recordsParameter = qry_new.OpenRecordset

    Leider funktionert dies nicht zuverlässig. Sehr häufig tritt der folgende Fehler auf:

    Laufzeitfehler 3011:
    Das MS Office-Access-Datenbankmodul konnte dasObjekt 'XlisteX' nicht finden.

    Die Liste exsitiert aber und kann als eingebundene Tabelle auch in Accesss direkt geöffnet werden. Dies allerdings auch nicht immer.

    Das Abfangen des Fehlers über on Error goto in VBA-Access funktioniert auch nicht zuverlässig, die Fehlermeldung wird anscheinend vom Treiber direkt geworfen.

    Jetzt die Fragen:

    Gibt es eine zuverlässige Methode des Zugriffs ?

    Wie kann ich die Fehlermeldung unterdrücken? (Ich muß dann halt erneut eine abfrage starten, um Daten zu erhalten.)

    Viele Grüße

    Thomas

     

    Dienstag, 14. September 2010 12:37

Antworten

  • Hi,

    Die Vorschläge mit CurrentDB etc. kann ich, ehrlich gesagt, nicht nachvollziehen. Was sollte das mit dem nur sporadisch auftretenden Fehler zu tun haben?

    Es ist doch offensichtlich so, dass JET mit dem Sharepoint-ISAM-Treiber nicht (immer) den Catalog abfragen kann bzw. dessen Ergebnis manche Listen nicht enthält. Sonst würde der Fehler doch nicht auch beim direkten Öffnen der verknüpften Liste auftreten.

    Das sieht mir auf den ersten Blick eher nach einem Problem mit der Kommunikation mit dem SP-Server aus. ... Was die nächsten Fragen aufwirft:

    - Um welche Access-Version handelt es sich; um welche Sharepoint-Version?

    - Wo steht der Server und wie stark wird er wodurch in Anspuch genommen?

    - Wie sieht der Verknüpfungsausdruck der Tabelle aus? (Tabellenentwurf > Eigenschaften)

    Interessant wäre darüber hinaus, ob JET noch weitere Meldungen zum Fehler ausgeben kann:

    > Nach dem 3011er-Fehler DbEngine.Errors(0).Description abfragen. Falls DbEngine.Errors.Count größer als 1 ist, dann auch Errors(1) abfragen.

    Ciao, Sascha

     


    Sascha Trowitzsch
    • Als Antwort markiert Thomas Eckel Freitag, 24. September 2010 20:28
    Mittwoch, 15. September 2010 11:53
  • Hallo,

    EckelTh wrote:

    also ich habe mal den code auf
    [...]
    angepasst.

    Dies wirft wie von Sascha vermutet, genauso den Fehler.

    Schade.

    Mit meiner Frage hier will ich sichergehen, daß es nicht eine Option in
    Access gibt, mit der ich das Problem umgehen kann.

    Gibt es nicht.

    Ich werde auf jeden Fall die Vorschläge zur weiteren Fehlerabfrage von
    Sascha mal einbauen. ( Erster Erfolg nach 3011 kam noch "3265|Element in
    dieser Auflistung nicht gefunden."

    Als Erfolg wuerde ich das nicht werten. ;-) Pruef mal die
    Tabellen-(Listen-) und Feldnamen.

    [...] O-ton des bisherigen Entwicklers -> Bei Apple wäre das aber
    gegangen.

    :-D

    Lass ihn den Beweiss antreten.

    Falls jemand noch eine Idee bzgl. des Problems hat, wäre ich für Infos
    sehr dankbar.

    Ich hab leider keinen Zugriff auf einen Sharepoint, kann nur mit SQL Server
    als BE testen und da ist die Situation so, dass bei eingebundenen Tabellen
    der Timeout offensichtlich nicht abgefangen werden kann, wohl aber, wenn
    der Zugriff per VBA geschieht, siehe Saschas Vorschlag. Wo die Timeouts in
    der Kombination SP und Provider veraendert werden koennen, entzieht sich
    meiner Kenntnis. Fuer ODBC bzw. SQL Server schlage ich immer hier nach:
    http://vyaskn.tripod.com/watch_your_timeouts.htm

    Gruss - Peter


    Mitglied im http://www.dbdev.org
    FAQ: http://www.donkarl.com

    • Als Antwort markiert Thomas Eckel Freitag, 24. September 2010 20:28
    Montag, 20. September 2010 17:16
    Moderator

Alle Antworten

  • Am 14.09.2010 schrieb EckelTh:

    ich habe eine Access-Lösung zusammengebaut, die auf Sharepoint-Listen zugreift. Die Listen sind über Importieren -> Sharepoint-Liste eingebunden. Der Zugriff erfolgt über DAO und dem folgenden Code:

    Dim qry_new As dao.QueryDef

    Dim db as DAO.Database
    Set db = CurrentDB

    Set qry_new = currentdb().Database.CreateQueryDef("")
    qry_new.SQL = qrySQL 'Hier wird ein gültiges SQL-statement eingefügt
    Set recordsParameter = qry_new.OpenRecordset

    Leider funktionert dies nicht zuverlässig. Sehr häufig tritt der folgende Fehler auf:

    Laufzeitfehler 3011:
    Das MS Office-Access-Datenbankmodul konnte dasObjekt 'XlisteX' nicht finden.

    CurrentDB hat den Vorteil, das es immer aktuell ist.

    Servus
    Winfried


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

    Dienstag, 14. September 2010 12:59
  • Hallo Winfried,

    hatte ich vielleicht etwas kurz dagestellt.

    Die Zeile  Set qry_new =  currentdb().Database.CreateQueryDef("") lautet eigentlich Set qry_new = projektDB.Database.CreateQueryDef("")
    mit projektDB als eigene Klasse, die bei Initialize projektDB = currentDB setzt. Diese Klasse wird halt für alle Queries genutzt.

    Stimmt dies mit Deinem Vorschlag überein oder sollte ich vor jeder Query dies neu setzen? Die aktuelle DB bleibt doch gleich, oder ?

    Viele Grüße
    Thomas

    Dienstag, 14. September 2010 13:06
  • Am 14.09.2010 schrieb EckelTh:

    hatte ich vielleicht etwas kurz dagestellt.

    Nicht nur zu kurz

    Die Zeile  Set qry_new =  currentdb().Database.CreateQueryDef("") lautet eigentlich Set qry_new = projektDB.Database.CreateQueryDef("")
    mit projektDB als eigene Klasse, die bei Initialize projektDB = currentDB setzt. Diese Klasse wird halt für alle Queries genutzt.

    sondern auch nicht die echten Zeilen gepostet. ;-(

    Stimmt dies mit Deinem Vorschlag überein oder sollte ich vor jeder Query dies neu setzen? Die aktuelle DB bleibt doch gleich, oder ?

    Sollte eigentlich, probiers aber mal mit meinem Vorschlag.

    Servus
    Winfried


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

    Dienstag, 14. September 2010 13:12
  • Hallo,

    EckelTh wrote:

    Die Zeile 
     Set qry_new =  currentdb().Database.CreateQueryDef("") lautet eigentlich
     Set qry_new = projektDB.Database.CreateQueryDef("")

    mit projektDB als eigene Klasse, die bei Initialize
     projektDB = currentDB setzt. Diese Klasse wird halt für alle Queries genutzt.

    Wozu hast du dafuer eine Klasse und was macht die sonst noch?

    Stimmt dies mit Deinem Vorschlag überein oder sollte ich vor jeder Query
    dies neu setzen? Die aktuelle DB bleibt doch gleich, oder ?

    Die DB-Variable bleibt, bis sie entweder vernichtet, oder der Kontext
    verlassen wird, d.h. wenn ProjektDB auf Prozedurebene deklariert worden
    ist, gilt sie nur fuer die Prozedur.

    Wenn die Listen als eingebundene Tabellen zur Verfuegung stehen, kannst du so vorgehen:

    Dim Db As DAO.Database
    Dim Rst As DAO.Recordset
    Dim Qry_New As DAO.QueryDef
    
    Set Db = CurrentDB
    Set Qry_New = Db.CreateQueryDef("", qrySQL)
    Set Rst = Qry_New.OpenRecordset
    
    'usw.
    'Am Ende aufraeumen:
    Rst.Close
    Set Rst = Nothing
    Set Qry_New = Nothing
    Set Db = Nothing

    Gruss - Peter


    Mitglied im http://www.dbdev.org
    FAQ: http://www.donkarl.com

    Dienstag, 14. September 2010 13:43
    Moderator
  • Hallo Winfried,

    sorry, ja ist blöd Code per Hand anzupassen und dann zu posten ohne diesen nochmal in einer kleinen Routine in Access zu testen. Ich werde mich bessern.

    Ich habe Deinen Vorschlag umgesetzt , leider tritt der Fehler sporadisch weiterhin auf. Einen Zusammenhang konnte ich leider noch nicht finden. Ich will aber z.B. die Belastung des Servers bzw. des Netzwerks nicht ausschliessen. Hierauf habe ich aber auch keinen Einfluß.

    Gibt es Möglichkeiten tiefergehend zu debuggen (ggf. auch über VS 2008-Debugger) ?

    Kann ich eventuelle Timeouts hochsetzen ?

    Gibt es eine Möglichkeit die Fehlermeldung abzufangen ? Ein "on Error goto" oder ein "resume next" funktionieren nicht für diesen Fehler.

    Viele Grüße
    Thomas

     

    Dienstag, 14. September 2010 13:51
  • Hallo Peter,

    ich habe das ganze von jemanden geerbt. Die Klasse macht sonst nichts mit dem CurrentDB-Objekt.

    Ich habe gerade mal deinen Code in einer Testroutine umgesetzt. Ich werde ihn mal ein wenig laufen lassen, um zu sehen ob es weiterhin zu der Fehlermeldung kommt.

    Viele Grüße

    Thomas

    Dienstag, 14. September 2010 14:07
  • Hi,

    Die Vorschläge mit CurrentDB etc. kann ich, ehrlich gesagt, nicht nachvollziehen. Was sollte das mit dem nur sporadisch auftretenden Fehler zu tun haben?

    Es ist doch offensichtlich so, dass JET mit dem Sharepoint-ISAM-Treiber nicht (immer) den Catalog abfragen kann bzw. dessen Ergebnis manche Listen nicht enthält. Sonst würde der Fehler doch nicht auch beim direkten Öffnen der verknüpften Liste auftreten.

    Das sieht mir auf den ersten Blick eher nach einem Problem mit der Kommunikation mit dem SP-Server aus. ... Was die nächsten Fragen aufwirft:

    - Um welche Access-Version handelt es sich; um welche Sharepoint-Version?

    - Wo steht der Server und wie stark wird er wodurch in Anspuch genommen?

    - Wie sieht der Verknüpfungsausdruck der Tabelle aus? (Tabellenentwurf > Eigenschaften)

    Interessant wäre darüber hinaus, ob JET noch weitere Meldungen zum Fehler ausgeben kann:

    > Nach dem 3011er-Fehler DbEngine.Errors(0).Description abfragen. Falls DbEngine.Errors.Count größer als 1 ist, dann auch Errors(1) abfragen.

    Ciao, Sascha

     


    Sascha Trowitzsch
    • Als Antwort markiert Thomas Eckel Freitag, 24. September 2010 20:28
    Mittwoch, 15. September 2010 11:53
  • Hallo Sascha,

    Sascha Trowitzsch [MVP] wrote:

    Die Vorschläge mit CurrentDB etc. kann ich, ehrlich gesagt, nicht
    nachvollziehen. Was sollte das mit dem nur sporadisch auftretenden
    Fehler zu tun haben?

    Wenn die Klasse nur CurrentDb setzt, garnichts. Aber warum braucht's dafuer
    eine Klasse, wenn nicht nochwas anderes gemacht wird?

    Gruss - Peter


    Mitglied im http://www.dbdev.org
    FAQ: http://www.donkarl.com

    Mittwoch, 15. September 2010 12:52
    Moderator
  • Hallo in die Runde,

    also ich habe mal den code auf

    Sub test_te_02()
    Dim Db As DAO.Database
    Dim Rst As DAO.Recordset
    Dim Qry_New As DAO.QueryDef
    
    Dim qrySQL As String
    
    qrySQL = "SELECT DISTINCT [Tabelle1].[Feld1] " & _
        "FROM [Tabelle2] INNER JOIN ([Tabelle1] INNER JOIN [Tabelle3] " & _
        "ON [Tabelle1].ID = [Tabelle3].[Feld2]) " & _
        "ON [Tabelle2].ID = [Tabelle3].Baureihe " & _
        "WHERE ((([Tabelle3].Baureihe) =5)) " & _
        "ORDER BY [Tabelle1].[Feld1];"
    
    
    Set Db = CurrentDb
    Set Qry_New = Db.CreateQueryDef("", qrySQL)
    Set Rst = Qry_New.OpenRecordset
      Debug.Print Rst.RecordCount
    Rst.Close
    Set Rst = Nothing
    Set Qry_New = Nothing
    Set Db = Nothing
    
    End Sub
    

    angepasst.

    Dies wirft wie von Sascha vermutet, genauso den Fehler. Ich habe keinen Zugriff und keine Informationen über den Server und den eingesetzten Versionen. Als Office Paket wird 2007 eingesetzt. Wie ich bereits angedeutet habe, vermute ich ein überlastetes Netzwerk oder Server. Ich erhalte die meiste Zeit die richtige und erwartete Anwort. Wie ich bereits angeführt habe, habe ich das Projekt geerbt. Der Tabellenentwurf ist Mist (das Wort Normalenform ist dem Entwickler unbekannt gewesen) und wurde auf Sharepoint-Seite angelegt.

    Mit meiner Frage hier will ich sichergehen, daß es nicht eine Option in Access gibt, mit der ich das Problem umgehen kann. Ich werde auf jeden Fall die Vorschläge zur weiteren Fehlerabfrage von Sascha mal einbauen. ( Erster Erfolg nach 3011 kam noch "3265|Element in dieser Auflistung nicht gefunden." 10 mal hat die Abfrage funkionert, dann ein paar mal nicht, dann geht die Abfrage wieder. Die Anzahl der zurückgegebenen recordsets bleibt gleich und stimmt.) Meiner Meinung nach läst dies auf schlechte Erreichbarkeit/Verfügbarkeit des WS- Services schliessen.

    Nach den bisherigen Antworten sieht es für mich danach aus, daß das Projekt so nicht sinnvoll umzusetzen ist. Die zuständige IT hat auch andere Nutzungsrichtlinien vorgegeben. O-ton des bisherigen Entwicklers -> Bei Apple wäre das aber gegangen. Soviel zum Stand der Dinge. Ich will mir nur nicht eine blutige Nase holen,weil ich eine Option übersehen habe, wenn ich der Meinung bin, dass diese Lösung wegen der Rahmenbedingungen so nicht funktionieren kann.

    @Peter
    Das Thema Klasse ist nicht die einzige Frage, die der Code aufwirft. (Ich hoffe Du verstehtst was ich meine) Aber dafür haben die langen Funktionen einen schönen Kommentarkopf mit Wer hat es verbrochen, welche Version (steht alles auf 1.0) ist es und welche Änderungen (hat halt noch keine gegeben) sind durchgeführt wurden. Funktionale Kommentare sind nur was für Anfänger :-)

    Falls jemand noch eine Idee bzgl. des Problems hat, wäre ich für Infos sehr dankbar.

    Vielen Dank an die Gemeinde

    Thomas

    Donnerstag, 16. September 2010 10:59
  • Hallo,

    EckelTh wrote:

    also ich habe mal den code auf
    [...]
    angepasst.

    Dies wirft wie von Sascha vermutet, genauso den Fehler.

    Schade.

    Mit meiner Frage hier will ich sichergehen, daß es nicht eine Option in
    Access gibt, mit der ich das Problem umgehen kann.

    Gibt es nicht.

    Ich werde auf jeden Fall die Vorschläge zur weiteren Fehlerabfrage von
    Sascha mal einbauen. ( Erster Erfolg nach 3011 kam noch "3265|Element in
    dieser Auflistung nicht gefunden."

    Als Erfolg wuerde ich das nicht werten. ;-) Pruef mal die
    Tabellen-(Listen-) und Feldnamen.

    [...] O-ton des bisherigen Entwicklers -> Bei Apple wäre das aber
    gegangen.

    :-D

    Lass ihn den Beweiss antreten.

    Falls jemand noch eine Idee bzgl. des Problems hat, wäre ich für Infos
    sehr dankbar.

    Ich hab leider keinen Zugriff auf einen Sharepoint, kann nur mit SQL Server
    als BE testen und da ist die Situation so, dass bei eingebundenen Tabellen
    der Timeout offensichtlich nicht abgefangen werden kann, wohl aber, wenn
    der Zugriff per VBA geschieht, siehe Saschas Vorschlag. Wo die Timeouts in
    der Kombination SP und Provider veraendert werden koennen, entzieht sich
    meiner Kenntnis. Fuer ODBC bzw. SQL Server schlage ich immer hier nach:
    http://vyaskn.tripod.com/watch_your_timeouts.htm

    Gruss - Peter


    Mitglied im http://www.dbdev.org
    FAQ: http://www.donkarl.com

    • Als Antwort markiert Thomas Eckel Freitag, 24. September 2010 20:28
    Montag, 20. September 2010 17:16
    Moderator
  • Hallo Peter,

    danke für die Antworten. Das mit dem Erfolg war nicht so ganz ernst gemeint.

    Die Feldnamen etc. passen soweit, die Abfrage liefert ja die richtigen Ergebnisse. (Wenn sie denn durchläuft).

    Ich denke, dass Problem löst sich durch Ablösung der gesamten Anwendung.

    Ich werde mal sehen, ob das Ändern der Timeout laut Deinem Link auch hier Auswirkungen haben. Wenn ja, werde ich das Ergebnis mitteilen.

    Vielen Dank

    Gruß

    Thomas

    Freitag, 24. September 2010 20:26