none
Umstellung von ADP's SQL-Server 2012: ODBC-Probleme mit Stored-Procedures RRS feed

  • Frage

  • Hallo zusammen,

    Ich habe den Aufruf meiner SP's 1:1 übernommen, bekomme aber jetzt dauernd Fehler, trotz identischer ODBC-Treiber und Versionen. Versucht hab ichs mit ODBC 11, SQL-Serer 11 native Client, SQL-Server Standardtreiber.DIe SP's auf dem Server sind korrekt, sonst würden Sie mittels der ADP nicht laufen. Benutzer hat dbo-rechte. Getestet mit MS-Access 2010 und 2016 ergibt folgenden Fehler:

    -2147217900 Unzulässige SQL-Anweisung; 'DELETE', 'INSERT', 'SELECT', 'PROCEDURE', oder 'UPDATE' erwartet.

    Variante1:
    ------------
    Set rst = New ADODB.Recordset
    With rst
           Set .ActiveConnection = CurrentProject.Connection
           .CursorType = adOpenStatic
           .LockType = adLockOptimistic
           .Source = "dbo.Recordsource_Forms_Betriebe '" & Buchstaben & "'"
           .Open
    End With
       
    If rst.BOF = True And rst.EOF = True Then
              MsgBox "Meldung " & StrAppname & vbCrLf & vbCrLf & " Zu dieser Selektion sind keine Datensätze vorhanden !", vbInformation, "Prüfung Zustellliste"
    Else
     Set Me.Recordset = rst
    End If

    Variante 2:
    ------------

     Set rst = cnn.Execute("dbo.Recordsource_Forms_Betriebe '" & Buchstaben & "'")
        If rst.BOF = True And rst.EOF = True Then
               MsgBox "Meldung " & StrAppname & vbCrLf & vbCrLf & " Zu dieser Selektion sind keine Datensätze vorhanden !", vbInformation, "Prüfung Zustellliste"
        Else
            Set Me.Recordset = rst
        End If

    Unterschied: Die ADSP bindet die Tabellen mit dem prefix dbo ein, die accdb ohne. Habe ich überall berücksichtigt, ausser beim Aufruf der SP's.

    Weiss da jemand was? Muss eigentlich was kleines sein:-)

    Gruss

    Peter

    Donnerstag, 23. März 2017 12:16

Antworten

  • Hallo Peter,

    Du schreibst, dass Du das accdb-Format verwendest. Das bedeutet, dass Du keine Projektdateien mehr verwenden kannst! Wenn Du eine Stored Procedure verwenden möchtest, dann musst Du im ADO-Command-Objekt auch als CommandType = adCmdStoredProc verwenden.

    Mit der folgenden Funktion erstelle ich mein Connection-Objekt (in Verbindung mit einer UDL-Datei)

    Public Function fn_app_CreateConnection() As ADODB.Connection
        On Error GoTo ErrorHandler:
        Dim ConnectionString As String
        ConnectionString = Replace("File Name=" & Environ("userprofile") & "\" & CONST_UDLFileName, "\\", "\")
        
        Set fn_app_CreateConnection = CreateObject("ADODB.Connection")
        With fn_app_CreateConnection
            .ConnectionTimeout = 0
            .CommandTimeOut = 0
            .Open ConnectionString
        End With
        
    ExitCode:
        On Error Resume Next
        Exit Function
    
    ErrorHandler:
        MsgBox Err.Description, vbInformation, "1. SQL-Server-Konferenz"
        Resume ExitCode
    End Function

    Um dann eine Stored Procedure auszuführen, verwende ich folgenden Code:

    ...
    
       Set cmd = New ADODB.Command
        With cmd
            Set .ActiveConnection = fn_app_CreateConnection()
            .CommandText = "dbo.proc_app_InsertCustomerData"
            .CommandType = adCmdStoredProc
            
            Set prm = .CreateParameter("@ReturnValue", adInteger, adParamReturnValue)
            .Parameters.Append prm
            
            Set prm = .CreateParameter("@CompanyName_01", adVarChar, adParamInput, 80, c.CompanyName_01)
            .Parameters.Append prm
            
            Set prm = .CreateParameter("@CompanyName_02", adVarChar, adParamInput, 80, c.CompanyName_02)
            .Parameters.Append prm
            
            Set prm = .CreateParameter("@CompanyName_03", adVarChar, adParamInput, 80, c.CompanyName_03)
            .Parameters.Append prm
    
            Set prm = .CreateParameter("@CCode", adVarChar, adParamInput, 3, c.CCode)
            .Parameters.Append prm
            
            Set prm = .CreateParameter("@Street", adVarChar, adParamInput, 80, c.Street)
            .Parameters.Append prm

    BTW: Du solltest aus mehreren Gründen IMMER mit Variablen arbeiten statt den SQL-Text zu konkatenieren:


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)


    Freitag, 14. April 2017 06:01

Alle Antworten

  • Hallo Peter,

    so richtig habe ich zwar nicht verstanden, was Du vorhast. Willst Du Tabellen via ODBC einbinden oder Recordsets via Stored Procedures füllen?

    Gruß Maik

    Freitag, 24. März 2017 12:01
  • Eigentlich geht es genau darum, ja..
    Freitag, 31. März 2017 13:49
  • Eigentlich geht es genau darum, ja..

    Die Antwort ist bei einer "a oder b" Frage ziemlich unsinnig, meinst Du nicht auch?

    So oder so: Probier mal, Recordset.Open mit entsprechenden Parametern aufzurufen, insbesondere dem Letzten (opt) mit adCmdStoredProc.

    Siehe dazu bspw.:

      https://www.w3schools.com/asp/met_rs_open.asp

    Alternativ kannst Du auch ein ADODB.Command verwenden. Siehe dazu:

      https://www.experts-exchange.com/questions/28461391/ADODB-Recordset-how-to-execute-stored-procedure-with-Open-command.html

    Oder einfach mal versuchen "EXEC <NameDerSp> ..." anzugeben.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Freitag, 31. März 2017 14:00
    Moderator
  • Nun ja, es ist ja nicht das erste mal, das ich eine sp verwende. Ich hätte ja auch nur A posten können, aber mit B sieht man ja auch noch, was ich sonst versucht habe:-)

    Ich verstehe einfach nicht, warum das identische Projekt, jetzt auf eine neue Access-ACCDB konvertiert, mit demselben ODBC-Treiber und unverändertem Code jetzt nicht mehr läuft..

    Der Fehler ist immer derselbe wie oben beschrieben

    Gruss

    Peter


    Freitag, 31. März 2017 14:23
  • Hallo Peter,

    hast Du denn mal den CommandType angegeben? Oder eben EXEC vor den Namen des SP geschrieben?


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Freitag, 31. März 2017 14:28
    Moderator
  • Hallo Stefan,

    Der Fehler ist -2147217900. Da findet google nix. Ohne das Minus gibts verschiedene Einträge, z.b.

    https://support.microsoft.com/de-ch/help/966146/run-time-error--2147217900-80040e14

    Da steht was mit Datenbank-Komptabilität im SQL-Server auf 80 setzen. Weiter runter als 90 komme ich allerdings nicht... 

    Interessanterweise wird der meiste Code trotzdem ausgeführt, wenn ich den Abfange mit

    If err.Number = -2147217900 Or err.Number = 91 Then Resume Next

    Mir ist aber nicht wohl dabei.

    Mit Joins wie im Artikel angemerkt hat das aber nix zu tun

    Code wie der nachfolgende tut dann aber widerum nicht:

    Set cnn = currentproject.connection

        Set rst = cnn.Execute("PlzOrtErmitteln " & CLng(Me!IDOrt))
        If Not rst.EOF Then
            Me!Postleitzahl.Value = Left(rst!PLZ.Value, 4)
            Me!Ort.Value = rst!Ort.Value
        End If

    läuft aber nicht.

    Lasse ich mein altes ADP-Projekt mit demselben Code, demselben SQL-Server und derselben Datenbank sowie demselben ODBC-Treiber laufen, tut alles ohne Probleme

    Ich steh echt aufm Schlauch...

    Gruss

    Peter

    Dienstag, 4. April 2017 17:58
  • Hallo Peter,

    Du schreibst, dass Du das accdb-Format verwendest. Das bedeutet, dass Du keine Projektdateien mehr verwenden kannst! Wenn Du eine Stored Procedure verwenden möchtest, dann musst Du im ADO-Command-Objekt auch als CommandType = adCmdStoredProc verwenden.

    Mit der folgenden Funktion erstelle ich mein Connection-Objekt (in Verbindung mit einer UDL-Datei)

    Public Function fn_app_CreateConnection() As ADODB.Connection
        On Error GoTo ErrorHandler:
        Dim ConnectionString As String
        ConnectionString = Replace("File Name=" & Environ("userprofile") & "\" & CONST_UDLFileName, "\\", "\")
        
        Set fn_app_CreateConnection = CreateObject("ADODB.Connection")
        With fn_app_CreateConnection
            .ConnectionTimeout = 0
            .CommandTimeOut = 0
            .Open ConnectionString
        End With
        
    ExitCode:
        On Error Resume Next
        Exit Function
    
    ErrorHandler:
        MsgBox Err.Description, vbInformation, "1. SQL-Server-Konferenz"
        Resume ExitCode
    End Function

    Um dann eine Stored Procedure auszuführen, verwende ich folgenden Code:

    ...
    
       Set cmd = New ADODB.Command
        With cmd
            Set .ActiveConnection = fn_app_CreateConnection()
            .CommandText = "dbo.proc_app_InsertCustomerData"
            .CommandType = adCmdStoredProc
            
            Set prm = .CreateParameter("@ReturnValue", adInteger, adParamReturnValue)
            .Parameters.Append prm
            
            Set prm = .CreateParameter("@CompanyName_01", adVarChar, adParamInput, 80, c.CompanyName_01)
            .Parameters.Append prm
            
            Set prm = .CreateParameter("@CompanyName_02", adVarChar, adParamInput, 80, c.CompanyName_02)
            .Parameters.Append prm
            
            Set prm = .CreateParameter("@CompanyName_03", adVarChar, adParamInput, 80, c.CompanyName_03)
            .Parameters.Append prm
    
            Set prm = .CreateParameter("@CCode", adVarChar, adParamInput, 3, c.CCode)
            .Parameters.Append prm
            
            Set prm = .CreateParameter("@Street", adVarChar, adParamInput, 80, c.Street)
            .Parameters.Append prm

    BTW: Du solltest aus mehreren Gründen IMMER mit Variablen arbeiten statt den SQL-Text zu konkatenieren:


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)


    Freitag, 14. April 2017 06:01
  • Hallo Uwe,

    Will erinfach nicht so richtig. Jetzt kommt die folgende Meldung:

    Das Microsoft Access-Datenbankmodul findet die Eingabetabelle oder Abfrage 'dbo.' nicht. Stellen Sie sicher, dass sie vorhanden ist und der Name richtig eingegeben wurde.

    bzw. beim Aufruf ohne dbo

    Das Microsoft Access-Datenbankmodul findet die Eingabetabelle oder Abfrage 'AuswertungLebensmittelkontrolle_Step1' nicht. Stellen Sie sicher, dass sie vorhanden ist und der Name richtig eingegeben wurde.

    Name der SP stimmt aber, diese funktioniert auch im MMC

    Mein derzeitiger Erguss:

     

    -----

    With cmd
                       .ActiveConnection = CurrentProject.Connection
                        .CommandText = "AuswertungLebensmittelkontrolle_Step1"
                        .CommandType = adCmdStoredProc
                        Set prm = .CreateParameter("SelText", adVarChar, adParamInput, 50, VarSeltext)
                        .Parameters.Append prm
                         'Set rst = .Execute
                        .Parameters.Delete (0)
      End With

    -----

    Sowas schön kompaktes klappt ebenfalls nicht:

    Set rst = cnn.Execute("SPName ") & Varname

    Hast Du auch eine DAO.Variante zur Hand?

    Gruss

    Peter

    Dienstag, 18. April 2017 12:29
  • Hallo Peter,

    was kommt denn bei "CurrentProject.Connection" heraus? Ich würde wetten, dass es sich um einen ACCESS-String handelt :)

    Provider=Microsoft.ACE.OLEDB.12.0;User ID=...

    Das kann natürlich nicht klappen. Du musst eine Verbindung zum SQL Server haben. Ich habe es so gelöst, dass ich zunächst eine neue Textdatei angelegt habe und sie zu .UDL umbenannt habe. Dann kannst Du mit einem Doppelklick die Verbindung konfigurieren. Aus meinem vorherigen Beispiel kannst Du erkennen, dass ich eine Funktion für die Verbindung zum SQL Server verwendet habe. Diese Funktion liefert ein CONNECTION-Objekt zurück, dass die Verbindung zum SQL Server beinhaltet.

    Wenn Du eine Stored Procedure verwenden möchtest, kannst Du das nur mit einer Pass Through Query oder mit meiner Variante durchführen. Folgendes Beispiel mal mit einer PT-Query:

    Option Compare Database
    Option Explicit
    
    Dim db As DAO.Database
    Dim qdef As DAO.QueryDef
    Dim rs As DAO.Recordset
    
    Sub ExecuteProc()
        On Error GoTo ErrorHandler
        
        Set db = CurrentDb()
        Set qdef = db.CreateQueryDef("")
        With qdef
            .Connect = "ODBC;DSN=dbCustomer;Description=SQL 2012;UID=YourName;PWD=Password;APP=Microsoft Office 2013;DATABASE=dbCustomer;"
            .SQL = "EXECUTE controls.proc_app_AvailableEmployees"
            .ReturnsRecords = True
            Set rs = .OpenRecordset
            While Not rs.EOF
                Debug.Print rs.Fields(1).Value
                rs.MoveNext
            Wend
        End With
        
    ExitCode:
        On Error Resume Next
        Set rs = Nothing
        Set qdef = Nothing
        Set db = Nothing
        Exit Sub
    
    ErrorHandler:
        Debug.Print Err.Description
        Resume ExitCode
    End Sub
    
    • Bitte denke daran, dass Du möglichst immer "full qualified" Objektnamen verwendest!
    • Denke auch daran, dass Du möglichst mit Parametern arbeitest um SQL Injection zu vermeiden


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Dienstag, 18. April 2017 17:14
  • Hallo Peter,
     
    Peter Steimann wrote:
     
    > Hast Du auch eine DAO.Variante zur Hand?
     
    Voila:
     
    Dim strSQL As String
    Dim strConnect As String
    Dim qExec As DAO.QueryDef
     
    strConnect = "ODBC;Driver=SQL Server Native Client 11.0;" & _
      "Server=DeinServer;Database=DeineDB;Uid=UserID;Pwd=Secret;"
     
    strSQL = "Exec DeineSP"
     
    Set qExec = CurrentDb.CreateQueryDef("")
    With qExec
     .Connect = strConnect
     .ReturnsRecords = False
     .ODBCTimeout = 0
     .SQL = strSQL
     .Execute dbSQLPassThrough + dbSeeChanges
     .Close
    End With
    Set qExec = Nothing
    Exit Function
     
    Gruss - Peter
     
    Donnerstag, 20. April 2017 13:31
  • Hallo Ihr lieben Helferlein,

    Ich kämpfe noch immer, bin momentan aber etwas stark im Druck:-)

    @Uwe, Du hattest Recht mit der Connection. Allerdings ging das so mit den ADP's... Ich werde nun alles auf DAO/TSQL/Passtrough umstellen, um nicht irgendwann wieder neu anfangen zu müssen, da MS ja auch ADO abgekündigt hat. 

    @Peter Ist das so generierte Recordset dann nicht read-only? Ich hab da noch Probleme mit Deinem Beispiel, falls ich Parameter (Filter) übergeben muss. Gibts sowas wie Dim Selektion as DAO.Parameter oder ähnlich?

    Gruss und Danke

    Peter 

    Mittwoch, 10. Mai 2017 09:00
  • Ich denke nicht, dass Microsoft ADO abgekündigt hat, da man sonst keinerlei Möglichkeiten mehr hätte ohne .NET oder Java überhaupt noch auf Datenbanken zugreifen zu können.

    Der Fehler 91 heißt, dass das gewünschte Objekt, auf das man zugreift, nicht erstellt wurde.
    Diesen Fehler zu ignorieren ist für die Anwendung tödlich.

    Hier findest du die Beschreibung, wie man mit einem Command-Object auf Prozeduren zugreift, was so auch erheblich einfacher ist:
    https://msdn.microsoft.com/de-de/library/ms676516%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

    Nur mit einem Recordset alleine geht das nicht, da man den Texttyp des Kommandos nur im Command-Object festlegen kann.
    Ggf. könnte es auch an der Erkennung des Parameters für die Prozedur liegen, da du kein Parameter-Objekt verwendest und deshalb die Prozedur nicht gefunden wird.
    Betrachte daher mal den Aufruf von CommandObject.Parameters.Refresh, der die Parameter korrekt definiert.

    Mittwoch, 10. Mai 2017 11:25
  • Nach Bernd Jungbluth ist das so. Da mich MS mit der Einstellung von ADP's und HTML-Forms unter MS-Access schon 1x im Regen stehen lies, geh ich da lieber auf nummer sicher..

    Über Google findet man da so einiges, z.B.

    https://social.msdn.microsoft.com/Forums/en-US/36dcc472-6393-481b-a523-5a661e5aa57a/sql-native-client-oledb-depreciation-and-recommendation-to-use-odbc?forum=sqldataaccess

    Gruss

    Peter

    Montag, 22. Mai 2017 10:14
  • Hallo Peter,

    Bernd hat Recht. OleDB ist seit längerem abgekündigt, auch wenn der Tod auf sich warten lässt: Converting SQL Server Applications from OLE DB to ODBC.

    Im Falle von Access sollte man darauf nicht warten. Denn Access funktionierte immer schon mit ODBC (und oftmals sogar besser).

    Da sich Stored Procedures / Passthrough Queries und Co. nur bedingt für die Bearbeitung eignen und eine vollkommen ungebundene Arbeitsweise bei Access auch nicht das Wahre ist:

    Verwende (über ODBC) verknüpfte Tabellen in den Fällen, wo der Aufwand nicht lohnt, sei es weil die Funktionen wenig benutzt werden oder sie nur mit relativ geringen Datemvolumen klar kommen müssen.

    Am Ende heißt es für Access mehr oder weniger "Back to the roots", in die Zeiten von Access 97 ;)

    Gruß Elmar

    Montag, 22. Mai 2017 10:23
    Beantworter
  • Nun, da handelt es sich um den OLEDB-Treiber des SQL-Servers. Dies hat nichts mit ADO zu tun.
    Es gibt schließlich noch andere Datenbanken, die durchaus effektiv mit OLEDB funktionieren und die gar keinen ODBC-Treiber mehr anbieten.

    ADO ist die vereinfachte objektorientierte Schnittstelle zu Datenbanken. An Stelle von ADO kann man bzgl. ODBC auch mit native CLI arbeiten. Dies ist aber leider nur ein C-Interface (noch nicht mal C++).

    Um als mit ODBC per ADO zu arbeiten, schaltet ADO einen Standard-OLEDB-Anbeiter (MSDASQL) dazwischen.
    Dieser ist allerdings seit ca. 1998 nicht mehr modernisiert worden und unterliegt daher ein paar Restriktionen, die ein nativer OLEDB-Treiber nicht hat.

    Betrachtet man dies im Zusammenhang, wird also bei ODBC eine zusätzliche Schicht eingezogen, die dann das CLI-Interface des ODBC-Treibers bedient.
    Mit OLEDB-Treibern könnte man also eine Aufrufebene sparen.

    Statt ADO kann man sicherlich auch DAO (Access) verwenden. Dies hat allerdings einen gewaltigen Nachteil.
    Es ist eine Access-MDB notwendig (nicht Access selber), diese ist u.U. nicht Multiuser-Fähig (z.B. auf Terminalserver), und sie vergrößert sich ständig (bis max. 2GB) und kann im laufenden Betrieb nicht verkleinert werden.

    Man kann also ruhig weiter mit ADO arbeiten und dann eben die Verbindung über ODBC herstellen.

    Den Hinweis, dass MSDASQL angeblich eingestellt werden sollte habe ich auf einer Seite von 2007 tatsächlich gefunden.
    Aktuell auf Server 2016 sowie Windows10 findet man die MSDASQL.DLL sowohl in der 32-Bit als auch 64-Bit-Version auf dem System.

    Eine Einstellung dieses Dienstes würde alle Datenbankanwendungen,  die ADO mit ODBC verwenden sofort killen. Ob Microsoft sich das allerdings leisten kann glaube ich eher nicht.

    Montag, 22. Mai 2017 10:44
  • Hmm, Das mit der Access-MDB möchte ich so nicht stehen lassen. Ich glaube, Du meinst statt z.B. TerminalServer wohl wirklich nur den Terminalserver:-) Abgesehen davon lässt sich dies auch auf dem Terminal-Server lösen, allerdings muss dann für jeden Client dort Access oder die Runtime sowie das Frontend installiert werden. Vergleichbar ist das Ganze vereinfacht damit , dass die ACCDB oder auch MDB als Frontend auf dem Server und nicht lokal auf dem PC gestartet wird:Eine absolute Totsünde in einer Mehrbenutzer-Umgebunng. Es geht zwar mit dem Parameter /excl, falls verschiedene Benutzer unregelmässigb/selten mit der Anwendung arbeiten. Nur wer weiss das so genau:-)

    Da spielt es denn aber keine Rolle, ob wir über den Zugriff via DAO oder ADO sprechen.

    Die DAO-Variante hat laut meinen Test den Vorteil, dass man sich 2 Vereweise (ADO) sparen kann und die Performance besser ist als mit ADO. TSQL "umgeht" nach meiner Recherche die Access-Engine, was sich hiebei positiv auf die Performance auswirkt.

    Deshalb gehe ich auf das gute alte DAO zurück, das wird so schnell wohl nicht abgekündigt werden..und ich ja ausschliesslich mit Access, ab und zu noch mit VB6  und SQL-Server arbeite:-)

    Montag, 22. Mai 2017 12:30
  • Hallo bfuerchau,

    deine Informationen sind einige Jahre veraltet.

    OleDb ist bereits vor Jahren von Microsoft als veraltet (legacy) erklärt worden - siehe den Link in meiner Antwort an Peter.

    Da ADO / OleDb über die Jahre außerhalb von Microsoft kaum Unterstützung erfahren hat, ist man zurück gekehrt zu ODBC (ein ISO/ANSI Standard). Heute existieren die Treiber für den SQL Server noch, weil sie bereits vorhanden waren und man bestehende Anwendungen weiter unterstützen wollte. (Und der SQL Server intern eine "light" Variante von OleDb verwendet)

    Der Rückzug ist einer der Gründe, wieso Microsoft Access keine nativen SQL Server Projekte (ADP) mehr unterstützt, da sie direkt für ADO / Ole Db konzipiert waren.

    Dass Ole Db jemals "besser" war als ODBC kann man in den Bereich der Mythen einsortieren. ADO wiederum funktioniert mit ODBC mehr schlecht als Recht, weil es um Ole Db als "vereinfachende" Schicht herum gebaut wurde.

    Andere Hersteller haben die Unterstützung, so überhaupt vorhanden, bereits ganz eingestellt. Neben ODBC wird eher .NET über native Provider unterstützt. Schlicht und einfach, weil diese einfacher zu realisieren sind, als der "hochkomplexe" Ole Db "Microsoft Standard".

    Was sich Microsoft leisten kann, zeigt auf der anderen Seite die lange Zeit fehlende Unterstützung von Mobil-/UWP-Anwendungen, selbst für die eigene Plattform. Da wurde man mit Hinweisen auf Azure, Web Services und "SQLite" abgespeist.

    Welche langfristigen Konsequenzen das für Desktop Anwendungen hat, zu denen auch Microsoft Access gehört, mag sich jeder selbst ausmalen.

    Gruß Elmar

    Montag, 22. Mai 2017 12:48
    Beantworter
  • Immerhin wird ADO mit Windows 10 noch unterstützt und ich denke und hoffe, dass dies noch eine Weile so bleibt.
    Die Native-ODBC-API's stehen ja nur in "C" zur Verfügung und somit habe ich ja dann nur C/C++ oder .NET für ODBC zur Verfügung.
    Alle nicht-C-Sprachen außer .NET, ins besonders diese, die COM unterstützen, wären dann von ODBC ausgeschlossen.
    Außerdem bieten die COM-Objekte eine Vielzahl von Zusatzfunktionen, die ich mir dann entweder wieder selber schreiben (Sortieren/Filtern/Suchen/Clonen) oder ggf. über Zusatz-Libs zukaufen muss, wobei ich zu letzterem nichts finde.
    Gerade die Einführung von ADO ca. 1997 mit MDAC hat das Entwickeln von Datenbankanwendungen extrem vereinfacht.
    Und was das DAO angeht, so wird dieses doch ausschließlich mit MS-Office installiert und das hat nicht jeder.
    Dazu gibt es ja noch folgende Aussage:

    DAO SDK Components Installed

    Note   Microsoft recommends using OLE DB or ODBC for new projects. DAO should only be used in maintaining existing applications.

    Da waeiß wohl die linke Hand nicht, was die rechte Hand gerade empfielt.
    Und was die lokalen MDB's angeht, so nutze ich hierfür die OLEDB-Jet.4.0-Treiber.


    Montag, 22. Mai 2017 14:30
  • Hallo Peter,
     
    Peter Steimann wrote:
     
    > @Peter Ist das so generierte Recordset dann nicht read-only? Ich hab da
    > noch Probleme mit Deinem Beispiel, falls ich Parameter (Filter)
    > übergeben muss. Gibts sowas wie Dim Selektion as DAO.Parameter oder
    > ähnlich?
     
    Es gibt kein Recordset. ;-) Es handelt sich um die Ausführung einer SP
    (.Execute), bei der keine Records zurückgegeben werden. Wenn die SP was
    aktualisieren soll, wird sie das auch tun, solange die Rechte am Server
    ausreichen.
     
    Wenn du einzelne Rows aktualisieren willst, ginge das auch per PT, aber
    dafür empfehle ich Elmars Vorschlag mit verknüpften Tabellen. Das hat den
    gewaltigen Vorteil, den Komfort des Access-Formulars nutzen zu können
    (Ereignisse, Aktualisierung, RecordSource usw.). Beachten musst du dabei
    nur, dass jede Tabelle einen PK enthält (eigentlich selbstverständlich),
    damit sie aktualisiert werden kann, und bei mehr als ein paar Feldern auch
    einen Timestamp.
     
    Gruss - Peter
     
    Dienstag, 30. Mai 2017 13:00