No, it's better that Access does not use ODBC - it uses the native JET/ACE software stack to do this. And thus the result is not only better but since there is no server when using a Access back end?
Then Access does not pull the whole table down the network wire as a result - this is good!!
Even when you use ADO? Well, the ODBC provider actually points to the oleDB provider, which then points to the native JET/ACE engine which of course is DAO.....
So, this is really just a issue of "common" confusing. But, as far as I can tell?
Access NEVER supported or used ODBC when using linked tables (to a access BE) - it's not a new thing - it's how Access always worked.
We the public just kind of "assumed" that Access worked this way - it does not, and never did......
Now, of course when linking to say SQL server?
Well, then yes, now your using ODBC drivers - but they are not used when linking to a Access back end...
So, you can of course use DAO, or ADODB for linked Access tables. Again still a choice.
Now, I don't want to open the ball of spaghetti called ADP projects.
When you use ADODB in Access? The existing table links can be used.
So, in above, like always, for the ADO example, then you have to use "%" for a wild cards (say like command) in place of the "*" when using DAO.
And thus you ALSO would not use "#" to surround dates like you do in DAO, but NOT with ADO.
And you can of course use DAO + ODBC, or ADODB + oleDB for linking to SQL server.
(but, to be fair, the recent editions of SQL server have stated they dropped support for using oleDB - which ADO uses). While they still support as such, Microsoft has stated that oleDB support is not supported!
Remember, oleDB is a windows only technology. ODBC is a true open standard, supported by Linux servers etc. So, Microsoft has and is dropping oleDB support for SQL server. And that means really ADO support for SQL server is going away in a round about way.
However, these days, that ADODB winds up having oleDB pointing to the ODBC driver for SQL server anyway. Again, either choice exists, again, no depreciation of features here in Access. So, the "going away" of ADO + oleDB support to SQL server? That's the result of SQL server going with ODBC - since that's not a windows only technology like oleDB is. ODBC is a true open standard, supported across multiple platforms and OS's.
So, not really any deprecation here I'm aware of in regards to Access.
The only depreciated feature that some "could" have noticed was the loss of so called JET-direct.
JET-direct allowed by-passing of the ODBC driver. And thus I believe it did give rise to some additional schema (catalog) features. And of course jet direct was also required for replication features which were also removed from ACE.
So, ADO or DAO both still work in Access......
Not a whole lot of reason to use ADO, but one such case would be if your being tasked to convert + migrate a ADO project.
Since all of the VBA recordset code would have been ADO, then I would suggest that one just leaves that code "as is", and not refactor to DAO.
(I would consider the refactor down the road after the ADP project is working, but even then, I would just continue to use and keep the existing ADO based code). However, this long advice of mine? (to keep the ADO code). Well, with SQL server going away from oleDB support, then yes, one now would give "higher" considering to convert the ADO code to DAO due to SQL server changes in technology directions.
My main reason for suggesting ODBC for linking Access FE's to accdb's was for improved resistance to corruption problems associated with the SMB protocol. MS did a good job in that area with improving the ODBC for SQL Server.
My main reason for suggesting ODBC for linking Access FE's to accdb's was for improved resistance to corruption problems associated with the SMB protocol. MS did a good job in that area with improving the ODBC for SQL Server.
That is correct. However, when you use ODBC to a file based system like a accdb file?
It's resolving to a file path, not a tc/ip socket connection.
It's still a file - even when using ODBC. And even if the file is sitting on a shared folder?
It's still a file, and standard windows file path name - there no kind of tc/ip socket connection occurring, and in ALL cases, the file open code is running on your local computer - not the remote server.
And that file open code?
Well, it's a standard file path, and it is STILL a standard windows file opening command running on your local computer.
You can't use a IP address to connect to a Access database, but ONLY a valid windows full path name.....
Introduction of ODBC does not change this, since you never connecting to a service, or a socket connection with some IP address, but are relegated to using the standard windows built in file open command.
Even using say .net or whatever, and the ODBC driver to open a access database?
That connection string not a IP address, but a standard windows file and path name will be required in that connection string....
It's a plain jane windows file open command being used here - even with a ODBC driver.....
You never are connecting to the access database, but in fact are using a windows file open command to "open" that file.
Not really different then opening a Word or Excel file.....
That is correct. However, when you use ODBC to a file based system like a accdb file?
It's resolving to a file path, not a tc/ip socket connection.
It's still a file - even when using ODBC. And even if the file is sitting on a shared folder?
It's still a file, and standard windows file path name - there no kind of tc/ip socket connection occurring, and in ALL cases, the file open code is running on your local computer - not the remote server.
And that file open code?
Well, it's a standard file path, and it is STILL a standard windows file opening command running on your local computer.
You can't use a IP address to connect to a Access database, but ONLY a valid windows full path name.....
Introduction of ODBC does not change this, since you never connecting to a service, or a socket connection with some IP address, but are relegated to using the standard windows built in file open command.
Even using say .net or whatever, and the ODBC driver to open a access database?
That connection string not a IP address, but a standard windows file and path name will be required in that connection string....
It's a plain jane windows file open command being used here - even with a ODBC driver.....
You never are connecting to the access database, but in fact are using a windows file open command to "open" that file.
Not really different then opening a Word or Excel file.....
