Re: Migrating away from MS-Access
- From: "John" <nospam@xxxxxxxxxx>
- Date: Mon, 15 Oct 2007 17:53:22 +1000
"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns99C9A3C3C27FCf99a49ed1d0c49c5bbb2@xxxxxxxxxxxxxxxxx
"Rick Brandt" <rickbrandt2@xxxxxxxxxxx> wrote in
news:yqoQi.2534$LD2.1642@xxxxxxxxxxxxxxxxxxxxxxxxxx:
There is ZERO point in building the same bad designs in your back
end on a SQL Server
I would disagree with that. Even a bad data structure could be safer
running on SQL Server than as an MDB. On the other hand, changing
the MDB data structure and deployment practices could also solve the
problems with the MDB version.
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.
.NET seems to be a very stupid choice, in my opinion.
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.
I think that somebody needs to sit down and document what's wrong
with the present app, then map out the different ways to solve the
problems that have been documented. Then that needs to be presented
to management to decide which they want to pursue.
With an experienced Access developer, the easiest way would be to
fix the existing Access app and the existing MDB's data schema.
Without that, I'm not sure what would be best. Perhaps migrating the
back end to a properly-structured SQL Server back end and modifying
the front end to work with that would be the best bet. It would
likely be the cheapest (absent the experienced Access developer).
I tend to agree with you however the front end is so badly done Id be very
suprised if it didnt need a rewrite to handle migrating the back end to sql
server. Having said that I havent tried it, and have never done it
before...but Im thinking im gonna start looking into that approach.
I do also tend to agree with what rick said in the access backend with
vb.net front is not real eligant...Im still relativly new to all that as
well, so I got a steep learning curve ahead of me. My experience is
approximatly 4-5 years with access and 1 year vb.net (doing not database
related stuff).
We are talking forms that rely on other forms to be open to work correctly,
storing fields that can be calculated, obscure table naming (+ spaces in
table names, eww), proper table relationships are not done, so ref integrity
is up the creek. Im not sure if its just me being a dumbass or not but Im
finding it increadibly difficult to wrap my head around the code, Im
literally scared to touch some things because god knows what its gonna do to
some other remote part of the app.....not a single peice of commenting or
documentation anywhere...
One thing I didnt mention was that there are other reasons besides dodgyness
we are moving to dotnet, which has to do with a few security concerns and
speed over terminal services (we are hoping webservices will be quicker) as
some offices are in remote locations...
All in all this is good information for me to think through! Thanks
guys...you guys are legends..
John
.
- Follow-Ups:
- Re: Migrating away from MS-Access
- From: David W. Fenton
- Re: Migrating away from MS-Access
- References:
- Migrating away from MS-Access
- From: John
- Re: Migrating away from MS-Access
- From: Rick Brandt
- Re: Migrating away from MS-Access
- From: David W. Fenton
- Migrating away from MS-Access
- Prev by Date: Re: Access 2003 & Vista
- Next by Date: Re: Migrating away from MS-Access
- Previous by thread: Re: Migrating away from MS-Access
- Next by thread: Re: Migrating away from MS-Access
- Index(es):
Relevant Pages
|
