[AccessD] Terrible performance like I have never seen before

Gustav Brock Gustav at cactus.dk
Thu Jul 8 11:29:19 CDT 2010


Hi Doug

Not to spoil the party neither the bill to the client ... but you could - as a first attempt - try to run the upsize wizard which will copy the tables to the SQL Server and establish ODBC connections to these. Some tweaking will be needed but the time for this is usually counted in days rather than months.

I've seen several apps running extremely well this way contrary to all the bad opinions regarding ODBC. That said, your app may of course be different and a rewrite may be the only way out but - as Jim has explained - the work load to achieve this is a magnitude larger and in some cases may not pay off and the time would have been spent better (and indeed at more fun) doing a complete rewrite with Visual Studio or the like.

/gustav


>>> dbdoug at gmail.com 08-07-2010 18:10 >>>
Hi Jim:

Thanks for the details.  All my forms (300+) are bound, and I have a couple
of thousand queries :(   I guess the logical first step is to start
unbinding the forms...

Doug

On Thu, Jul 8, 2010 at 8:11 AM, Jim Lawrence <accessd at shaw.ca> wrote:

> Hi Doug:
>
> My approach was rather straight forward but there is not real quick way to
> do it right hence the nearly month long odyssey to get the system moved.
> Fortunately the client was on a monthly contract so I could spread the work
> out over a couple of months as they are not likely to just accept a 10K
> bill...but as they are on a monthly contract that is exactly what they will
> pay. ;-)
>
> I installed a MS SQL on the client's site and used the Upsizing wizard to
> construct all the tables on the SQL and rebuilt all the queries in Stored
> Procedures. (I have done this before so I have all basics are pre-built
> like: Add, Delete, Update, first, next, previous, last, goto-record... with
> their associated UDF (User defined function... same as a function in
> Access)) The queries have to be rebuilt to compile with SP standards.
>
> The application usually has to under go a few changes.
> No bound... that is what a SQL server is for; it does the data management.
> I
> populate all the forms, reports, list and combo boxes via recordsets. I
> usually populate a form one record at a time as it is usually so fast that
> the client doesn't notice any delays.
>
> Those recordsets are assembled through a SQL interface module. Rather than
> go into a page by page explanation suffice to say its sole purpose is to
> connection with the SQL, retrieve and update recordsets through an ADO OLE
> interface. The only tricky parts can be from dealing with combo boxes and
> reports but newer versions of Access take a lot of the grunt work out.
>
> If you want to know more I will answer you questions one at a time.
>
> Jim





More information about the AccessD mailing list