Re: Migrating away from MS-Access

John wrote:
Hello there, Im cursing my place of employment...and its taken me a
month to realise it...

The scenario:
Ive just stepped into a role to migrate an access database to VB.Net.
The access database runs on terminal services and supports
approximatly 25-30 users. It is crapping out big time, corrupted
data, changes to the front end are difficult for someone unfamiliar
with the system (me), the table structure is bad...really
bad....there is a website attached to the backend aswell...

At some stage we have to migrate the access backend to SQL Server. The
problem is that its all in use and we cannot have downtime.

What approach is best? How can I even fix this dodgy design?

I could just run with it and build dodgyness over
dodgyness...fark...haha god help the next guy if i did that...
I could convince management to hire someone else to develop in
parrallel on both systems so the backend is fixed?
I could develop the new VB.net front end with changes in mind, then
fix the database structure when we migrate
I could migrated access backend to sqlServer backend and continue to
use the Access front end, I very much suspect the front end will fall
into a big pile of crap...

I guess Im not really looking for answers, just venting and curious
to see what other people have delt with...
Thanks for reading!
John


A dot-net front end with an MDB file back end is the worst of all worlds.
Develop both the new dot-net front end (if you are stuck with that questionable
decision) and SQL Server back end separately until they are tested enough to
migrate all of the data over. That is especially true if the existing table
structures are poorly designed.

There is ZERO point in building the same bad designs in your back end on a SQL
Server and even less point in building a new front end that will take as much
time and resources as dot-net will only to connect it to a table structure that
is known to be deficient.

In my opinion creating an improved back end on the SQL Server and then using a
modified version of your Access front end is likely to be the simplest and
fastest solution and one where you will be most satisfied with the result. You
can of course do this in stages. There is no reason to feel that ALL of the
tables need to be migrated at one time to SQL Server. Groups of tables that are
related should be kept together, but individual groups and some supporting
tables can be moved separately.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com





.

Relevant Pages

  • Re: QUESTION???
    ... Robert Morley wrote: ... stored on SQL Server, so that will be large, but the Access database will ... backend, Is my size of my MS Access program be affected considering i have a ...
    (microsoft.public.access.adp.sqlserver)
  • Re: New front end application
    ... I need to connect the SQL Server as backend, ... How do I save the Access database as an application? ... Blank datat access page... ...
    (microsoft.public.access.gettingstarted)
  • Re: tool to re-reference forms after usizing?
    ... Speed Ferret (which I hate to admit that I've never been able to get to ... tblCustomerAddress, remember that changing tblCustomer to something else ... >>> I am in the process of upsizing an access database to sql server. ...
    (microsoft.public.access.conversion)
  • Re: ODBC parameters and system resources
    ... Install MSDE or use an existing SQL Server. ... I connect to an Access database of about 500MB in size. ... there is the "Not enough space on temporary disk". ... What can a "System resource" be apart from disk space and RAM? ...
    (comp.databases.ms-access)
  • Re: Replication Suggestions
    ... Looking for a SQL Server replication book? ... >I have an application with a sql backend. ... > database on the webbox and an internal database for inter-company use. ...
    (microsoft.public.sqlserver.replication)