Re: Convert to ADO for SQL Server back end

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

The rule more or less is, "for Jet objects, use DAO, for SQL Server
objects, use ADO".

Performance-wise, use pass-through queries as much as possible (you
can manipulate them in DAO code). Also use Jet to cache static data in
local tables so you don't have to make a round trip over the network
to fill a combo box. Get into the mindset that you're creating a web
app or a .NET, except with Access as the FE instead of a browser.

--Mary

On Sun, 15 Jan 2006 07:58:56 GMT, "robert d via AccessMonster.com"
<u6836@uwe> wrote:

>I've read through some posts on the ADO vs. DAO question. Most seem to be
>around a year or so old.
>
>So: I have an Access app that uses almost exclusively unbound forms and DAO
>for data access. A potential client won't accept the Jet backend and demands
>SQL Server.
>
>I did some preliminary work and upsized my Jet tables to SQL server. I also
>created ODBC links to the SQL Server tables from my front end. No conversion
>of DAO to ADO.
>
>Everything seemed to work pretty well. In fact, the app runs quite a bit
>faster accessing data from SQL server than it does from the Jet backend on a
>server.
>
>So, since I would have to convert about 400 DAO recordsets, I'm not sure I
>want to bother. Maybe the app would be faster with ADO to SQL Server, but it
>is currently faster using DAO to SQL Server than DAO to Jet. So the point is,
>it is not slower. Maybe that means nothing, but on the other hand, I think
>it means I don't have an immediate problem. So why kill myself doing the
>conversion.
>
>Thoughts, suggestions are greatly appreciated.
.

Relevant Pages