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

John wrote:

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

Hi,

as far as i see it (if you've similar problems than I have): the main
problem ist diving DEEP into .net and SQL server (ie your knowledge)

So the best solution would be to do that project together with a good
"mentor". You develop, but your metor helps you to avoid the biggest traps.

My personal favour would be to bet on VS 2008 together with LINQ and
Silverlight 1.1 ...

I think it's mainly a question of convincing the right people that the money
they put into education/mentoring is worth while ...

mfg

Klaus

On Sun, 14 Oct 2007 22:39:38 +1000, "John" <nospam (AT) nospam (DOT) com> wrote:

Confronted with these problems I would first put band-aids on the
existing app in those areas that are used the most. Then I would
redesign the db and work on the new UI and a data conversion program
that copies as much as possible data from old to new db.
If you are unfamiliar with the users needs, you'll need to spend a
fair amount of time analyzing those needs, and getting buy-in from
management for the new design.

-Tom.

"David W. Fenton" wrote

I once worked for a manager who taught me more than he realized he was
teaching, and from whom I learned far more than I realized, at the time,
that I was learning. His favorite aphorism: "There are only two times in
the project life-cycle to engage in planning. <Pause> Early and often."

Larry

"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote

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

No way man...

I wouldnt touch new Microsoft technology with a 10 foot pole.....ALWAYS stay
3 or 4 years behind or your askin for it...

Well thats my philosophy anyway, its stood me in good stead so far...but
then I took on this job, so haha, im a dumbass!

A mentor would be damn handy.....but yeah, programmers cost money Wish
they were free...I find books to be good for learning overall architecture
and probably as good as a mentor, but for those little coding gotcha things
its nice to have someone else around...
John


"Klaus Oberdalhoff" <kobd (AT) gmx (DOT) de> wrote

All sounds like good wisdom to me!

"Larry Linson" <bouncer (AT) localhost (DOT) not> wrote

On Oct 15, 3:58 am, "John" <nos... (AT) nospam (DOT) com> wrote:

How much does it cost to have 25-30 users working with a database
described as:
"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"?

lol true, worthy point...in my initial report to management I said something
of the sort....so hopefully it wont be an uphill battle to get another as
they werent too off put by it...in the meantime I have the old programmer
(or jack of all trades man) coming in once a week...

"lyle" <lyle.fairfield (AT) gmail (DOT) com> wrote