Re: Should I worry that my Access to SQL conversion has gone so well?

Tech-Archive recommends: Fix windows errors by optimizing your registry



Bobby

Having migrated over 10 applications from an Access/JET back-end to a
SQL-Server back-end, then re-linking from the front-end(s) for my day job,
you seem to have covered it all. There might be a few more "tuning" issues,
but I don't recall anything other than performance and SQL-Server
permissions issues that bit me.

I'd be curious, though, what qualifications the person had who told you that
you would have to rewrite the front-end in VB.NET? Any chance s/he was a
VB.NET programmer?<g>

Regards

Jeff Boyce
Microsoft Office/Access MVP


"Bobby" <bobby2@xxxxxxxxxxxxxxxx> wrote in message
news:1154441774.158154.132940@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I've been set the task of converting a 20 user Access 2003 database to
SQL server 2000.

The original access version is two databases, a front end and a back
end. The front end uses about 40 forms. Without using the upsizing
wizard, I have simply imported the backend into SQL, made a few changes

to data types, and set a few primary keys etc., and then linked the
front end to the SQL database using ODBC.

The two main issues I have encountered are 1) poor performance due to
various counts and sums in fields on forms, (so I have removed these or

found work arounds) and 2) I have a sub form which uses an access query

with two tables. In Access the sub form will allow me to add new items,

but in SQL it won't. I'm not sure why yet, but can probably find a work

around to this. Any suggestions would be gratefully received.

Now that I have resolved issue 1 (above) everything seems nice and fast

(certainly no slower than the access version was), and although I still

have a lot more testing to complete, my 6 month project seems to have
been almost completed in a week.

Should I be worried??? It seems too easy. Have I gained anything my
moving from an Access back end to SQL in this way? Before I started I
was given all kinds of dire warnings about having to re-write my front
end in VB.NET. Why was it so easy??? Something nasty must be waiting
around the corner. Any suggestions what it might be?


Bobby



.



Relevant Pages

  • Re: CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to
    ... Go to the Database tab and click on the browse button next to the connection string. ... In the New Database Reference dialog, enter the details for the database where you want to deploy the assembly and create the user defined aggregate. ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to meth
    ... Now register the assembly and the aggregate in the SQL Server database you want ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... But SQL does not have a pointer data type or the ... > being told to design a database. ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: DBMS and lisp, etc.
    ... Naively implemented with SQL, again for 10 ... (1 query for the initial orders, 1 query for each order for its ... soon as you upgrade to the SQL database. ... (eq (order-customer orderA) ...
    (comp.lang.lisp)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... a surrogate key should support the primary key. ... But SQL does not have a pointer data type or the ... > being told to design a database. ...
    (comp.databases.theory)