Migrating away from MS-Access

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

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

Re: Migrating away from MS-Access

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

Re: Migrating away from MS-Access

On Sun, 14 Oct 2007 22:39:38 +1000, "John" 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.


>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
>

Re: Migrating away from MS-Access

"Rick Brandt" wrote in
news:yqoQi.2534$LD2.1642@newssvr17.news.prodigy.net:

> 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).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

Tom van Stiphout wrote in
news:59h4h3pvcv8uqv3oat79neb8bqmd9d0qtr@4ax.com:

> 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.

I think the project sounds like it needs significant further
planning before any work is begun. Without an agreed-upon document
that outlines exactly what's wrong with the existing app, how can
you ever know if you're on the right track in terms of what the
bosses want?

If I were hired as an outside contractor on this project, the first
thing I'd do is schedule meetings with all the constituencies and
then budget for somewhere between 16 and 32 hours of time
documenting the structure and deficiencies of the current app, with
an eye towards using that as the basis for the proposal for building
the new app.

Planning is never wasted in these kinds of scenarios.

Experience has taught me that assuming you understand what the
customer wants is guaranteed to lead to misunderstandings and
problems in the long run.

As my father always worded the carpenter's main principle:

Measure twice and cut once.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"David W. Fenton" wrote

> Planning is never wasted in these kinds of scenarios.

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. Early and often."

Larry

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99C9A3C3C27FCf99a49ed1d0c49c5bbb2@216.196.97.142...
> "Rick Brandt" wrote in
> news:yqoQi.2534$LD2.1642@newssvr17.news.prodigy.net:
>
>> 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

Re: Migrating away from MS-Access

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" wrote in message
news:fetcnk$62d$01$1@news.t-online.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
>

Re: Migrating away from MS-Access

All sounds like good wisdom to me!

"Larry Linson" wrote in message
news:JivQi.16495$uC1.16485@trnddc04...
> "David W. Fenton" wrote
>
> > Planning is never wasted in these kinds of scenarios.
>
> 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. Early and often."
>
> Larry
>

Re: Migrating away from MS-Access

On Oct 15, 3:58 am, "John" wrote:

> A mentor would be damn handy.....but yeah, programmers cost money .

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"?

Re: Migrating away from MS-Access

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" wrote in message
news:1192438640.872988.113380@k35g2000prh.googlegroups.com.. .
> On Oct 15, 3:58 am, "John" wrote:
>
>> A mentor would be damn handy.....but yeah, programmers cost money .
>
> 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"?
>

Re: Migrating away from MS-Access

"John" wrote in message
news:fet2p80at7@news5.newsguy.com...
>
> What approach is best? How can I even fix this dodgy design?
>

In a nutshell ... I would take a copy of everything and fix both the BE and
FE, documenting every step very carefully, ask users to rigorously test the
"fix" and then repeat the cycle until everyone is happy. Then do it on the
real system using the documented steps. There would be downtime, I don't
think you can avoid it, but your "practice" phase ought to keep it to a
minimum.

You could then think about migrating your new, lean application to another
system if necessary.

Not rocket science, I know, just my 2p worth :-)

Keith.
www.keithwilby.com

Re: Migrating away from MS-Access

On Oct 15, 5:37 am, "Keith Wilby" wrote:

> In a nutshell ... I would take a copy of everything and fix both the BE and
> FE, documenting every step very carefully, ask users to rigorously test the
> "fix" and then repeat the cycle until everyone is happy.

But how do you know your grandchildren will WANT to be Access
developers?

Re: Migrating away from MS-Access

"John" wrote in
news:fev6df01u8j@news4.newsguy.com:

> 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...

It's not you.

If I were handed a project like this, the first thing I'd do would
be refactoring everything to come up to my coding standards. That
means changing no functionality at all, and just converting it to be
done right. That would involve steps in this order:

1. use Speed Ferret to fix all the naming problems.

2. go through the code sub/function by sub/function and fix the
formatting and naming conventions. Change *no* functionality at all.

3. fix the dependencies on other forms without changing
functionality. That is, just make the most minimal changes to get
rid of the dependencies and do it right.

Obviously, step 1 involves both the front end and back end.

The point here is to do something with the code that makes it better
without actually changing what it does or how it works. The process
of doing this will force you to become familiar with the application
as it stands now, and will then enable you to understand what needs
to be redesigned/replaced.

Only after a refactoring would I then embark on trying to fix the
design problems.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

On Mon, 15 Oct 2007 19:03:11 +1000, "John" wrote:

To program? That would be a mistake.
To document? Sure.
-Tom.


>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" wrote in message
>news:1192438640.872988.113380@k35g2000prh.googlegroups.com. ..
>> On Oct 15, 3:58 am, "John" wrote:
>>
>>> A mentor would be damn handy.....but yeah, programmers cost money .
>>
>> 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"?
>>
>

Re: Migrating away from MS-Access

Actually...well put....

I have been letting him program......you are right...thats a mistake...he is
only good for documentation....no more programming for him, just
documentation day....

Thanks!
John

"Tom van Stiphout" wrote in message
news:n9b8h3pa6s62cuml982hr92iegaqvbcqar@4ax.com...
> On Mon, 15 Oct 2007 19:03:11 +1000, "John" wrote:
>
> To program? That would be a mistake.
> To document? Sure.
> -Tom.
>
>
>>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" wrote in message
>>news:1192438640.872988.113380@k35g2000prh.googlegroups.com ...
>>> On Oct 15, 3:58 am, "John" wrote:
>>>
>>>> A mentor would be damn handy.....but yeah, programmers cost money .
>>>
>>> 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"?
>>>
>>

Re: Migrating away from MS-Access

Hi John,

I dont know if it has been said yet, but I though I might suggest that
one of the first things that you should do is to make a copy of
EVERYTHING and burn it to a cd/dvd. Having a backup is essential to
not causing yourself a heart attack.

Outside of that lilsten to these guys - they know what they are doing.

Cheers

The Frog

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99CAAD811F97f99a49ed1d0c49c5bbb2@216.196.97.142...
> "John" wrote in
> news:fev6df01u8j@news4.newsguy.com:
>
>> 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...
>
> It's not you.
>
> If I were handed a project like this, the first thing I'd do would
> be refactoring everything to come up to my coding standards. That
> means changing no functionality at all, and just converting it to be
> done right. That would involve steps in this order:
>
> 1. use Speed Ferret to fix all the naming problems.
>
> 2. go through the code sub/function by sub/function and fix the
> formatting and naming conventions. Change *no* functionality at all.
>
> 3. fix the dependencies on other forms without changing
> functionality. That is, just make the most minimal changes to get
> rid of the dependencies and do it right.
>
> Obviously, step 1 involves both the front end and back end.
>
> The point here is to do something with the code that makes it better
> without actually changing what it does or how it works. The process
> of doing this will force you to become familiar with the application
> as it stands now, and will then enable you to understand what needs
> to be redesigned/replaced.
>

Cool thanks for the reassurance, I think you are spot on the money with
those steps too...I've begun the process of documenting all the name
changes, then I will do those steps, 1, 2, 3...then I will migrate the
backend to SQL Server....then look at migrating the front end to VB.net,
that'll be a while off tho...hopefully I can get management to hire another
to worry about VB.net...which has already been in production for a year...if
they hadnt have started that itd be much easier and for all I know could be
a waste of resources going that path if I can get access going right...

Thanks man
John

Re: Migrating away from MS-Access

"John" wrote in
news:ff1q420v1e@news5.newsguy.com:

> then look at migrating the front end to VB.net,
> that'll be a while off tho...hopefully I can get management to
> hire another to worry about VB.net...which has already been in
> production for a year...if they hadnt have started that itd be
> much easier and for all I know could be a waste of resources going
> that path if I can get access going right...

I think migrating the front end to VB.NET is a bloody stupid idea. I
see no benefit in it at all -- just a huge additional cost (maybe
3-5 times as much as fixing the Access front end to work with SQL
Server). Does your employer have a solid justification for wanting
to use VB.NET? You certainly haven't mentioned it if they have.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

On Oct 16, 11:32 am, "David W. Fenton"
wrote:
> "John" wrote innews:ff1q420v1e@news5.newsguy.com:
>
> > then look at migrating the front end to VB.net,
> > that'll be a while off tho...hopefully I can get management to
> > hire another to worry about VB.net...which has already been in
> > production for a year...if they hadnt have started that itd be
> > much easier and for all I know could be a waste of resources going
> > that path if I can get access going right...
>
> I think migrating the front end to VB.NET is a bloody stupid idea. I
> see no benefit in it at all -- just a huge additional cost (maybe
> 3-5 times as much as fixing the Access front end to work with SQL
> Server). Does your employer have a solid justification for wanting
> to use VB.NET? You certainly haven't mentioned it if they have.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

Well the previous programmer blamed access for all his woes...that I believe
was the primary reason for going to VB.net...The other primary reason was
security (Which I know very little about, he may have been right, he may
have been wrong...)...

I think there are possibly a few other reasons such as wanting to operate a
cut down version on mobile devices

The few reasons I think are probably valid;
- Security, we do have some fairly complicated security requirements, which
im still learning about.
- Speed running over terminal services (We have remote locations that im
told run very slowly over terminal services, I hope a webservice is faster)
- The user interface is nicer, easier to control, with access I find that
there are lots of things you *can* do, but probably shouldnt...I know this
is weak :)
- Just recently, 2 weeks ago, I got informed we may have a sudden doubling
of users, then doubling again....yeah umm great :) So I think vb.net is
safer.
- Multideveloper is easier if that ever happens, although this is probably
moot because of the twice as long thing :)

But yeah in all honesty id much rather be working in access, its faster,
easier to do things, half the reasons for vb.net are flimsy at best, so it
will warrant some more thought and discussion with the head honcho...but I
doubt very much we will change course however...a portion of the users are
using the dotnet version and once that happens theres no going
back....they've seen all the developer express pretty pretty stuff....it
LOOKS great....it must be better...

John




"David W. Fenton" wrote in message
news:Xns99CB752DC1ABDf99a49ed1d0c49c5bbb2@216.196.97.142...
> "John" wrote in
> news:ff1q420v1e@news5.newsguy.com:
>
>> then look at migrating the front end to VB.net,
>> that'll be a while off tho...hopefully I can get management to
>> hire another to worry about VB.net...which has already been in
>> production for a year...if they hadnt have started that itd be
>> much easier and for all I know could be a waste of resources going
>> that path if I can get access going right...
>
> I think migrating the front end to VB.NET is a bloody stupid idea. I
> see no benefit in it at all -- just a huge additional cost (maybe
> 3-5 times as much as fixing the Access front end to work with SQL
> Server). Does your employer have a solid justification for wanting
> to use VB.NET? You certainly haven't mentioned it if they have.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
>

Re: Migrating away from MS-Access

"John" wrote in
news:ff3ii30jf8@news1.newsguy.com:

> Well the previous programmer blamed access for all his woes...that
> I believe was the primary reason for going to VB.net...The other
> primary reason was security (Which I know very little about, he
> may have been right, he may have been wrong...)...

Can your employers explain exactly how VB.NET solves either of these
problems?

Security is a *back-end* issue, not a front-end one, so that's
irrelevant.

The rest sounds to me like the carpenter blaming his tools. New
tools won't raise the skill level of the carpenter.

> I think there are possibly a few other reasons such as wanting to
> operate a cut down version on mobile devices

VB.NET enables that, but I don't believe it's an *easy* thing.

And, of course, there's a Windows Terminal Server client for Windows
Mobile.

> The few reasons I think are probably valid;
> - Security, we do have some fairly complicated security
> requirements, which im still learning about.

Has nothing to do with Access.

> - Speed running over terminal services (We have remote locations
> that im told run very slowly over terminal services, I hope a
> webservice is faster)

Eh? That's a function of:

1. bandwidth

2. server provisioning.

If an Access app runs slow on Terminal Server, it probably runs
slowly on the desktop.

In other words, irrelevant to the front-end platform, and entirely
due to problems elsewhere.

> - The user interface is nicer, easier to control, with access I
> find that there are lots of things you *can* do, but probably
> shouldnt...I know this is weak :)

Again, this is about the programmer's skill level, not about what
the platform can or can't do. I can't think of anything essential to
a database application that an Access app can't do. Care to cite an
example?

I will say that it certainly is true that you often must avoid the
default approaches suggested by the Access sample files (such as
binding a form to a table).

> - Just recently, 2 weeks ago, I got informed we may have a sudden
> doubling of users, then doubling again....yeah umm great :) So I
> think vb.net is safer.

Why? User population is not relevant to your *front end* -- it's
only relevant to the back end.

> - Multideveloper is easier if that ever happens, although this is
> probably moot because of the twice as long thing :)

It can be done with Access, which can be used with VSS.

> But yeah in all honesty id much rather be working in access, its
> faster, easier to do things, half the reasons for vb.net are
> flimsy at best, so it will warrant some more thought and
> discussion with the head honcho...but I doubt very much we will
> change course however...a portion of the users are using the
> dotnet version and once that happens theres no going
> back....they've seen all the developer express pretty pretty
> stuff....it LOOKS great....it must be better...

It already exists? I don't recall you're having said that, unless
you're referring to the web app that uses the MDB data store.

It looks to me as though *all* the problems would be solved by
keeping the Access front end and migrating the back end to SQL
Server. None of the problems would be solved by keeping the MDB back
end and migrating the front end to anything at all.

So, that would make it pretty clear what the best plan of attack
would be, no?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99CCB62AA969Bf99a49ed1d0c49c5bbb2@216.196.97.142...
> "John" wrote in
> news:ff3ii30jf8@news1.newsguy.com:
>
>> Well the previous programmer blamed access for all his woes...that
>> I believe was the primary reason for going to VB.net...The other
>> primary reason was security (Which I know very little about, he
>> may have been right, he may have been wrong...)...
>
> Can your employers explain exactly how VB.NET solves either of these
> problems?
>
> Security is a *back-end* issue, not a front-end one, so that's
> irrelevant.
>
> The rest sounds to me like the carpenter blaming his tools. New
> tools won't raise the skill level of the carpenter.
>

yeah Id tend to agree....

>> I think there are possibly a few other reasons such as wanting to
>> operate a cut down version on mobile devices
>
> VB.NET enables that, but I don't believe it's an *easy* thing.
>
> And, of course, there's a Windows Terminal Server client for Windows
> Mobile.
>
>> The few reasons I think are probably valid;
>> - Security, we do have some fairly complicated security
>> requirements, which im still learning about.
>
> Has nothing to do with Access.
>

point taken..

>> - Speed running over terminal services (We have remote locations
>> that im told run very slowly over terminal services, I hope a
>> webservice is faster)
>
> Eh? That's a function of:
>
> 1. bandwidth
>
> 2. server provisioning.
>
> If an Access app runs slow on Terminal Server, it probably runs
> slowly on the desktop.
>
> In other words, irrelevant to the front-end platform, and entirely
> due to problems elsewhere.
>


Im not sure as Ive never done it before, but my logic was that if only
information is being sent via soap stuff i'd hope that was quicker than
sending screen changes via term services...that is the application would be
deployed on their computer...Having said that its not something ive had time
to research yet....


>> - The user interface is nicer, easier to control, with access I
>> find that there are lots of things you *can* do, but probably
>> shouldnt...I know this is weak :)
>
> Again, this is about the programmer's skill level, not about what
> the platform can or can't do. I can't think of anything essential to
> a database application that an Access app can't do. Care to cite an
> example?
>
> I will say that it certainly is true that you often must avoid the
> default approaches suggested by the Access sample files (such as
> binding a form to a table).
>


Why not bind a form to a table?


>> - Just recently, 2 weeks ago, I got informed we may have a sudden
>> doubling of users, then doubling again....yeah umm great :) So I
>> think vb.net is safer.
>
> Why? User population is not relevant to your *front end* -- it's
> only relevant to the back end.
>

True, you are right

>> - Multideveloper is easier if that ever happens, although this is
>> probably moot because of the twice as long thing :)
>
> It can be done with Access, which can be used with VSS.

ahh I didnt know that...I'll scope that out...

>
>> But yeah in all honesty id much rather be working in access, its
>> faster, easier to do things, half the reasons for vb.net are
>> flimsy at best, so it will warrant some more thought and
>> discussion with the head honcho...but I doubt very much we will
>> change course however...a portion of the users are using the
>> dotnet version and once that happens theres no going
>> back....they've seen all the developer express pretty pretty
>> stuff....it LOOKS great....it must be better...
>
> It already exists? I don't recall you're having said that, unless
> you're referring to the web app that uses the MDB data store.
>

It half exists, essentially they decided vb.net was the way to go before I
came along and started the process of a rewrite....so a portion of the users
are using it because it has a different set of functionality....the old guy
was even given a bonus to get certain functionality working before he
left....*shudder* (here have some money to fuck it up even more for the next
guy)...I believe it has been a year in since he started the rewrite, and its
all built on a messy backend...

> It looks to me as though *all* the problems would be solved by
> keeping the Access front end and migrating the back end to SQL
> Server. None of the problems would be solved by keeping the MDB back
> end and migrating the front end to anything at all.
>
> So, that would make it pretty clear what the best plan of attack
> would be, no?
>

yeah, I think so....essentially it all boils down to the access backend is a
mess, the access front end is a mess, the old programmer decided vb.net was
the way to solve it, started along that path....

But you are right, there are no *good* reasons to go to vb.net....so its a
matter of choosing whatever existing front end is better to go with....in
terms of whats gonna be easier to fix and move on with...which kinda does
look like access...

It's all giving me a headache at the moment ,so I havent processed this
email as well as I would of liked...I will revisit it later and have a good
think...
Thanks man
John

Re: Migrating away from MS-Access

"David W. Fenton" wrote:

I completely agree with David's comments.

>> - Speed running over terminal services (We have remote locations
>> that im told run very slowly over terminal services, I hope a
>> webservice is faster)
>
>Eh? That's a function of:
>
>1. bandwidth
>
>2. server provisioning.
>
>If an Access app runs slow on Terminal Server, it probably runs
>slowly on the desktop.
>
>In other words, irrelevant to the front-end platform, and entirely
>due to problems elsewhere.

Just to expand on this. I've used TS over a 28.8 kpbs phone line. It was sluggish
but it worked. When using Access over a DSL connection to a client with a DSL
connection it's fast enough that I don't even realize it's not local.

So the problem there is not with Access.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Migrating away from MS-Access

MS-Access/VBA developer since 1991.

*** Sent via Developersdex http://www.developersdex.com ***

Re: Migrating away from MS-Access

In my experience, if you convert your Access tables directly over to SQL
Server and do not modify the front end code, you will end up with a
slower application. Regular SQL queries will still need to pull all the
data down from the server before it can process it. All of the existing
SQL queries will need to be converted to stored procedures to see any
type of performance gain.

Also, if the entire Access database resides on the server, this will
cause a performance issue. First try and split front end from backend
(data) and place the front end on the users desktop. I am sure you can
find several possible solutions to update the users front end
automaticaly as modifications are made to it. Later try and pull as many
not core data tables out of the back end and into the front end as they
are found. These tables are usually static tables used for drop downs,
temporary data handling, etc...

Next try and do as much query processing on the front end as possible.
For example if you are running a complex account report lets say, first
just pull down all required fields from all of that account records for
the report. Then do the remaining queries on the front end...



*** Sent via Developersdex http://www.developersdex.com ***

Re: Migrating away from MS-Access

Per John Casey:
>In my experience, if you convert your Access tables directly over to SQL
>Server and do not modify the front end code, you will end up with a
>slower application.

I've had similar experiences: client mandates that we move tables
to client-server DB and just ODBC and keep the same queries. We
say "That's a bad idea". They say "Just do it".

Performance in 3 cases went from sub-second response time to
several seconds.

What upset me in those cases is that my name was on the app as
the last guy to touch it.
--
PeteCresswell

Re: Migrating away from MS-Access

"John" wrote in
news:ff68tn0su@news3.newsguy.com:

> "David W. Fenton" wrote in message
> news:Xns99CCB62AA969Bf99a49ed1d0c49c5bbb2@216.196.97.142...
>> "John" wrote in
>> news:ff3ii30jf8@news1.newsguy.com:
>>

>>> - Speed running over terminal services (We have remote locations
>>> that im told run very slowly over terminal services, I hope a
>>> webservice is faster)
>>
>> Eh? That's a function of:
>>
>> 1. bandwidth
>>
>> 2. server provisioning.
>>
>> If an Access app runs slow on Terminal Server, it probably runs
>> slowly on the desktop.
>>
>> In other words, irrelevant to the front-end platform, and
>> entirely due to problems elsewhere.
>
> Im not sure as Ive never done it before, but my logic was that if
> only information is being sent via soap stuff i'd hope that was
> quicker than sending screen changes via term services...

Well, you're assuming certain things:

1. that, in fact, the amount of information being sent *is* smaller.

2. the time rendering in the client and using substandard widgets is
going to be less than the amount of time taken sending the image.

> that is the application would be
> deployed on their computer...Having said that its not something
> ive had time to research yet....

You may be wrong in what you believe is sent across the wire by
Terminal Server. It's not a bit map (like VNC), but the primitive
graphics commands that Windows sends to the graphics subsystem. This
is pretty high-level and efficient, since it's vector-based (partly)
and not bit-mapped. So it's very fast.

Given how well it works across 28.8. dialup, I can't imagine why it
would be a problem running on any decent WAN.

>>> - The user interface is nicer, easier to control, with access I
>>> find that there are lots of things you *can* do, but probably
>>> shouldnt...I know this is weak :)
>>
>> Again, this is about the programmer's skill level, not about what
>> the platform can or can't do. I can't think of anything essential
>> to a database application that an Access app can't do. Care to
>> cite an example?
>>
>> I will say that it certainly is true that you often must avoid
>> the default approaches suggested by the Access sample files (such
>> as binding a form to a table).
>
> Why not bind a form to a table?

Because it's pulling too much information and serves no purpose for
the end user. A form that displays one record at a time doesn't need
any data except the data for that one record. Why pull over the data
necessary to display the whole table?

>>> But yeah in all honesty id much rather be working in access, its
>>> faster, easier to do things, half the reasons for vb.net are
>>> flimsy at best, so it will warrant some more thought and
>>> discussion with the head honcho...but I doubt very much we will
>>> change course however...a portion of the users are using the
>>> dotnet version and once that happens theres no going
>>> back....they've seen all the developer express pretty pretty
>>> stuff....it LOOKS great....it must be better...
>>
>> It already exists? I don't recall you're having said that, unless
>> you're referring to the web app that uses the MDB data store.
>
> It half exists, essentially they decided vb.net was the way to go
> before I came along and started the process of a rewrite....so a
> portion of the users are using it because it has a different set
> of functionality....the old guy was even given a bonus to get
> certain functionality working before he left....*shudder* (here
> have some money to fuck it up even more for the next guy)...I
> believe it has been a year in since he started the rewrite, and
> its all built on a messy backend...

Ah. The VB.NET app is not *finished*.

Then I'd say you have a good chance, even if you're inexperienced,
to fix the Access app long before the other app is ever finished.

>> It looks to me as though *all* the problems would be solved by
>> keeping the Access front end and migrating the back end to SQL
>> Server. None of the problems would be solved by keeping the MDB
>> back end and migrating the front end to anything at all.
>>
>> So, that would make it pretty clear what the best plan of attack
>> would be, no?
>
> yeah, I think so....essentially it all boils down to the access
> backend is a mess, the access front end is a mess, the old
> programmer decided vb.net was the way to solve it, started along
> that path....

And made a new mess.

> But you are right, there are no *good* reasons to go to
> vb.net....so its a matter of choosing whatever existing front end
> is better to go with....in terms of whats gonna be easier to fix
> and move on with...which kinda does look like access...

My guess is that it would be cheaper to chuck the VB.NET app
entirely, convert the back end to SQL Server and fix the Access
front end than it would be to finish the VB.NET app. And it will be
faster.

> It's all giving me a headache at the moment ,so I havent processed
> this email as well as I would of liked...I will revisit it later
> and have a good think...

I think your superiors are the ones who need a good think, but they
clearly don't have correct information. Perhaps direct them to this
discussion (assuming you haven't said anything embarassing!).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

John Casey wrote in
news:47188bc2$0$3581$815e3792@news.qwest.net:

> In my experience, if you convert your Access tables directly over
> to SQL Server and do not modify the front end code, you will end
> up with a slower application. Regular SQL queries will still need
> to pull all the data down from the server before it can process
> it.

This is just not true. Jet is very smart, and hands off many, many
of the queries to the server, and just returns the results. If you
look at the Jet SHOWPLAN, it shows exactly that. And if you use
Profiler on your SQL Server, you'll see that SQL Server then uses
the generic SP to make the query passed by Jet into a SP dynamically
and automatically.

Certain types of queries (updates, deletes, inserts) can be *very*
inefficient, though, because, for instance, an insert of 100 records
will get sent by Jet as 100 separate 1-record inserts (each of which
is then run through the generic SP). This is annoying to the
developer, but good behavior on Jet's part, since it allows the SQL
Server to serialize each line, rather than it being taken over by a
long action query. In that case, it's usually better to either use a
passthrough or a stored procedure.

> All of the existing
> SQL queries will need to be converted to stored procedures to see
> any type of performance gain.

Not at all true. *Some* things will need to be converted. Some will
not.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

Per David W. Fenton:
>This
>is pretty high-level and efficient, since it's vector-based (partly)
>and not bit-mapped. So it's very fast.
>
>Given how well it works across 28.8. dialup, I can't imagine why it
>would be a problem running on any decent WAN.

I didn't want to say anything, but now I've got to chime in to
support David's assertion.

I do most of my development work via Remote Desktop Connection
over VPN tunnels.

I've got Verizon's most el-cheapo FIOS service: touted at 5mbps,
but I'll bet it never gets over 4.... yet my perceived
performance is good enough to work all day and never be conscious
of being on Remote Desktop. There's occasionally a little bit
of mouse delay, but that's it.

One client has a WAN pipeline from Penna to their London office
and I'm going to try VPN-ing across that as soon as I can. Guys
from London that are visiting here use it all day and claim "no
problem".
--
PeteCresswell

Re: Migrating away from MS-Access

> Well, you're assuming certain things:
>
> 1. that, in fact, the amount of information being sent *is* smaller.
>
> 2. the time rendering in the client and using substandard widgets is
> going to be less than the amount of time taken sending the image.
>

I think you are right again...I feel like such a noob :)


>>>> - The user interface is nicer, easier to control, with access I
>>>> find that there are lots of things you *can* do, but probably
>>>> shouldnt...I know this is weak :)
>>>
>>> Again, this is about the programmer's skill level, not about what
>>> the platform can or can't do. I can't think of anything essential
>>> to a database application that an Access app can't do. Care to
>>> cite an example?
>>>
>>> I will say that it certainly is true that you often must avoid
>>> the default approaches suggested by the Access sample files (such
>>> as binding a form to a table).
>>
>> Why not bind a form to a table?
>
> Because it's pulling too much information and serves no purpose for
> the end user. A form that displays one record at a time doesn't need
> any data except the data for that one record. Why pull over the data
> necessary to display the whole table?
>

I discussed this with the old guy today amongst other things...he dismissed
it...I have done a little reading on this since the last post, and I see how
it would solve alot of our problems, but it is a significant rewrite....lol
every path is a signicant rewrite tho....but I can't say im entirly sold on
them being any less work than say developing a vb.net form.


>>> It looks to me as though *all* the problems would be solved by
>>> keeping the Access front end and migrating the back end to SQL
>>> Server. None of the problems would be solved by keeping the MDB
>>> back end and migrating the front end to anything at all.
>>>
>>> So, that would make it pretty clear what the best plan of attack
>>> would be, no?
>>
>> yeah, I think so....essentially it all boils down to the access
>> backend is a mess, the access front end is a mess, the old
>> programmer decided vb.net was the way to solve it, started along
>> that path....
>
> And made a new mess.
>

lol yeah :( I will grant he has done a somewhat better job at the vb.net,
but that doesnt help a great deal cause of the backend...

>> But you are right, there are no *good* reasons to go to
>> vb.net....so its a matter of choosing whatever existing front end
>> is better to go with....in terms of whats gonna be easier to fix
>> and move on with...which kinda does look like access...
>
> My guess is that it would be cheaper to chuck the VB.NET app
> entirely, convert the back end to SQL Server and fix the Access
> front end than it would be to finish the VB.NET app. will be
> faster.
>

I must admit Im still slightly inclined to go the vb.net route, (dispite me
agreeing with everything everyone has said so far, maybe im crazy), I think
once we start having to do things like unbound forms and massive rewrites,
while it would still be quicker to go access, I dont consider vb.net to be
hugly more expensive.

I do think that it is definitly the case the front end needs a 70-80%
rewrite to work with sqlserver There must be reasons why people develop in
VB.net. This is how I think of it;

Access Advantages
Developing a data access layer is where all the work is for VB.Net. Access
has already done this, so there is no work.


VB.NET
The user interface is much quicker to develop robustly in VB.Net utilising
inheritance and user controls.
Data validation is easier
Im just reading a post by Albert D Kallal, lol and David W Fenton, and all
the guru's, lol, I think is a good thread that has alot of merit.
http://groups.google.com/group/comp.databases.ms-access/brow se_thread/thread/8053a3b03a7162c6/879440056ce94e1b?hl=en&lnk =st&q=vb.net+vs+access#879440056ce94e1b

right now thats taking a long time to read :) I think it may boil down to a
decision as to weather the project is big enough to warrent developing the
data access layer....but clearly I need to do more research....as those 3
things were the only I could think of off the top of my head....


>> It's all giving me a headache at the moment ,so I havent processed
>> this email as well as I would of liked...I will revisit it later
>> and have a good think...
>
> I think your superiors are the ones who need a good think, but they
> clearly don't have correct information. Perhaps direct them to this
> discussion (assuming you haven't said anything embarassing!).
>

Yeah, I am working on a report to hand to them and I have verbally informed
them that I think a change in tact is in order, and I must admit they were
pretty cool about it, and I think Im getting another developer in the pipe
line, and they do trust what I say and are going along with whatever I
say...I would dearly love to hand them this, and I may do so, I am a bit
weary of how I've bagged out the old developer as he is still around in the
woodworks for a while and I still need him. Also I really wanna verify that
I am correct to be bagging him out....while thats my gut feeling, ya cant go
around doing that unless you are really sure and can confidently back it
up....and while all the arguements presented here are sound, it all hinges
on how correct my analysis of the existing state of the code is. In honesty
if I was asked now, I couldnt say 100% confidently say for sure that it is
REALLY bad, I can say its messy, much dodgier than Ive ever done, my gut
feeling is its really bad, but Im still in the process of analysing all the
tables and scoping out the real requirements.....

John

Re: Migrating away from MS-Access

ugg, just realised my posting details have changed...I used to read as
"John" ...now im
"NewsGuy" wrote in message
news:ffcepe0d1n@news5.newsguy.com...

Ive only just returned to this group after a few years absense, I notice
there is another guy called John...thats not me....:) I wonder if thats
confusing...

Installed Vista on my home puta......yes, Im asking for more pain....but so
far.....mostly good....

I guess I should mention that I do realise VB.net will take longer....its a
case of weather its worth it keeping in mind a large system that it may one
day grow into...

I dunno, also no one really wants to work with access is the general vibe I
get...some people scoff at me when I tell them Im an access developer...but
yeah I guess only fools listen to fools....I wonder how the employment
market is for access developers and if/when we get another if that has any
merit for analysis...

John

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:ffcgoc0fg3@news5.newsguy.com:

> ugg, just realised my posting details have changed...I used to read as
> "John" ...now im
> "NewsGuy" wrote in message
> news:ffcepe0d1n@news5.newsguy.com...
>
> Ive only just returned to this group after a few years absense, I
> notice there is another guy called John...thats not me....:) I wonder
> if thats confusing...
>
> Installed Vista on my home puta......yes, Im asking for more
> pain....but so far.....mostly good....
>
> I guess I should mention that I do realise VB.net will take
> longer....its a case of weather its worth it keeping in mind a large
> system that it may one day grow into...
>
> I dunno, also no one really wants to work with access is the general
> vibe I get...some people scoff at me when I tell them Im an access
> developer...but yeah I guess only fools listen to fools....I wonder
> how the employment market is for access developers and if/when we get
> another if that has any merit for analysis...
>
> John

In my opinion:
- Most databases are crap, beginning with the original northwind sample
from ms;
- Most institutions assign database development and maintenance to
someone inadequate;
- Most upper-level managers do not understand the value of a
comprehensive, well-designed, efficient database;
- Many upper-level managers do not want a comprehensive, well-designed,
efficient database because it can threaten their power to do whatever
they want;
- Many developers and sa's use system databases as a support for their
own personal fiefdom;
- Many developers and sa's use system databases inappropriately for their
own personal enjoyment, aggrandizement or profit;
- Security in most databases is a joke;
- Many IT personnel have no background in programming yet feel fully
qualified to evaluate Access and other technologies.

Developers deal with these disagreeable facts every day. It's what we do!
Making a few pretty Access forms and a couple of official looking Access
reports is five per cent of our work. We get paid $80 or $100 per hour to
deal get into the swamp and battle with the alligators. It's life.

My last task yesterday was to figure out why we had one too many
(distinct) site names in a table we imported from a excel workbook.
Simple: the workbook had an Orchard #2 (one space) and an Orchard #2
(two spaces). So I created a regular expression replace that grabbed only
the Uppercase alpha-numeric characters from the excel school names and
compared them.
Then I was told our totals weren't the spreadsheet's total which were
public and "official". Why? Well the spreadsheet showed integers but
added decimals. Their totals were wrong? Maybe they are, depending upon
your point of view and level of education. What to do? I referred that
one to my contact. What shall we use? 10 + 10 + 10 = 31, or 10.3 + 10.3 +
10 .3 = 30.9 or 10 + 10 + 10 = 30. Oh simple, use the spreadsheet totals,
right? Not so simple, we do f(10) and f(10) + f(10) + f(10) has to add up
to f(their total); and the 10 is ten people, bodies; in the real world we
simply don't have 31 bodies.

These are no big deal, but such things are a big part of any developer's
work.

I am suggesting that you are not alone.


--
lyle fairfield

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:ffcepe0d1n@news5.newsguy.com:

> must admit Im still slightly inclined to go the vb.net route,
> (dispite me
> agreeing with everything everyone has said so far, maybe im
> crazy),

I'd say going the VB.NET route would be crazy, yes.

> I think
> once we start having to do things like unbound forms and massive
> rewrites, while it would still be quicker to go access, I dont
> consider vb.net to be hugly more expensive.

But you *don't* have to do unbound forms in Access. All you have to
do to make it perform well is to properly filter the data you're
retrieving to meet the immediate needs of the user. That does *not*
require creating unbound forms.

For what it's worth, in 11 years of professional Access development,
I've implemented unbound forms less than a dozen times. But I've
implemented lots of forms that load a single record or a small group
of records.

> I do think that it is definitly the case the front end needs a
> 70-80% rewrite to work with sqlserver

Well, first, how much work would it take to make the Jet back end
properly structured and to adapt the front end to work with that?
That part should *not* be considered part of the SQL Server
conversion at all. Once youv'e figured that out, then you'd want to
estimate what it would take to convert the back end to SQL Server,
and my bet is that it's relatively trivial (though it's very hard
without experience to forecast exactly which parts of the app will
need to be adapted/moved to the SQL Server).

> There must be reasons why people develop in
> VB.net.

I think it's because they don't know any better. VB.NET *is* better
for a VB developer who wants to do Internet-enabled apps. But for
Access developers, it lacks a lot.

> This is how I think of it;
>
> Access Advantages
> Developing a data access layer is where all the work is for
> VB.Net. Access has already done this, so there is no work.

I think you're underestimating a lot of what Access has to offer.

> VB.NET
> The user interface is much quicker to develop robustly in VB.Net
> utilising inheritance and user controls.

Huh? Since when? Access has a whole host of controls and objects
specifically designed for use with databases, most of which
VB/VB.NET lack. Sure, VB.NET is better with databound controls than
VB, but still there is nothing to compare to an Access continuous
form for ease of use. And the event models are much poorer for the
tasks of data editing than the Access form/control event model.


> Data validation is easier

Howso?

> Im just reading a post by Albert D Kallal, lol and David W Fenton,
> and all the guru's, lol, I think is a good thread that has alot of
> merit.
> http://groups.google.com/group/comp.databases.ms-access/brow se_thre
> ad/thread/8053a3b03a7162c6/879440056ce94e1b?hl=en&lnk=st&q=v b.net+v
> s+access#879440056ce94e1b

That thread certainly makes the point about unbound forms not being
required to create a good app in Access.

> right now thats taking a long time to read :) I think it may boil
> down to a decision as to weather the project is big enough to
> warrent developing the data access layer....but clearly I need to
> do more research....as those 3 things were the only I could think
> of off the top of my head....

I would vote against the data access layer. But, of course, I'm
operating without first-hand information about the app.

I think that many people from the C/S side of things overengineer
their apps, and a separate data access layer to an app that is
currently operating with a Jet back end sounds like complete
overkill. If a data access layer is necessary, then the app couldn't
work at all with a Jet back end.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

Per NewsGuy:
> I think
>once we start having to do things like unbound forms and massive rewrites,
>while it would still be quicker to go access, I dont consider vb.net to be
>hugly more expensive.

I keep hearing that from people who probably know, but for the
one app that I took the time to develop in both VB6 and MS Access
the ratio was somewhere between three and five to one (got it
recorded somewhere... but can't recall exactly).

But based on the dollars billed by a large company's IT
department when they replaced two of my MS Access apps with
net-centric (I know for sure one was .Net... not sure about the
other) I'd expect the .Net ratio tb more like 10:1.

Been meaning to master enough of .Net to prove or disprove that
suspicion for about five years now... but never got around to it.

Maybe you can report back if/when you do it.

Also... there are those who would argue that in the whole life
cycle of an application, the initial development time is
chickenfeed anyhow.
--
PeteCresswell

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99CFA1332AAA8f99a49ed1d0c49c5bbb2@216.196.97.142...
> "NewsGuy" wrote in
> news:ffcepe0d1n@news5.newsguy.com:
>
>> must admit Im still slightly inclined to go the vb.net route,
>> (dispite me
>> agreeing with everything everyone has said so far, maybe im
>> crazy),
>
> I'd say going the VB.NET route would be crazy, yes.
>

lol :) Perhaps...im in a flip flop mood today...im going round in circles a
bit....need to take a break to get some objectivity... right now I'm
thinking yeah, Access is much faster, if I just did a complete rewrite of
the access front end it would be dandy, but still thers a "but..." in the
back of my mind....

>> I think
>> once we start having to do things like unbound forms and massive
>> rewrites, while it would still be quicker to go access, I dont
>> consider vb.net to be hugly more expensive.
>
> But you *don't* have to do unbound forms in Access. All you have to
> do to make it perform well is to properly filter the data you're
> retrieving to meet the immediate needs of the user. That does *not*
> require creating unbound forms.
>
> For what it's worth, in 11 years of professional Access development,
> I've implemented unbound forms less than a dozen times. But I've
> implemented lots of forms that load a single record or a small group
> of records.
>
>> I do think that it is definitly the case the front end needs a
>> 70-80% rewrite to work with sqlserver
>
> Well, first, how much work would it take to make the Jet back end
> properly structured and to adapt the front end to work with that?
> That part should *not* be considered part of the SQL Server
> conversion at all. Once youv'e figured that out, then you'd want to
> estimate what it would take to convert the back end to SQL Server,
> and my bet is that it's relatively trivial (though it's very hard
> without experience to forecast exactly which parts of the app will
> need to be adapted/moved to the SQL Server).
>
>> There must be reasons why people develop in
>> VB.net.
>
> I think it's because they don't know any better. VB.NET *is* better
> for a VB developer who wants to do Internet-enabled apps. But for
> Access developers, it lacks a lot.
>
>> This is how I think of it;
>>
>> Access Advantages
>> Developing a data access layer is where all the work is for
>> VB.Net. Access has already done this, so there is no work.
>
> I think you're underestimating a lot of what Access has to offer.
>
>> VB.NET
>> The user interface is much quicker to develop robustly in VB.Net
>> utilising inheritance and user controls.
>
> Huh? Since when? Access has a whole host of controls and objects
> specifically designed for use with databases, most of which
> VB/VB.NET lack. Sure, VB.NET is better with databound controls than
> VB, but still there is nothing to compare to an Access continuous
> form for ease of use. And the event models are much poorer for the
> tasks of data editing than the Access form/control event model.
>

Yeah, you are right, tho there are certain difficulties to do a few things
on continuous forms...for example say having an editable textbox that shows
tax inclusive/exclusive and binds the exclusive value to the field is a bit
of a mess...

I guess I like the fact that in VB.Net I know it can be done, even if it
takes longer, I know I can get it to do whatever is required, I dont have
that confidence with access....

I think probably this and this reason alone is why alot of people lean
towards VB.net based things...

One instance of this is, say the toolbar, in VB.Net we have it different
depending on the user who is logged in, in Access we just pop up a msgbox
saying you do not have security to use this...its no biggie, but its just
not eligant...weather the boss wants to pay for that kind of elegance I
guess is what counts...


>> Data validation is easier
>
> Howso?
>

Well ya can just have inherited validation that just requires one line of
code...in access I've always had a whole lot of procedural based validation
and sometimes alot of if thens...but maybe this is my inexperience
showing...but I guess its not a big thing, certainly nothing to base a
migration on...

>> Im just reading a post by Albert D Kallal, lol and David W Fenton,
>> and all the guru's, lol, I think is a good thread that has alot of
>> merit.
>> http://groups.google.com/group/comp.databases.ms-access/brow se_thre
>> ad/thread/8053a3b03a7162c6/879440056ce94e1b?hl=en&lnk=st&q=v b.net+v
>> s+access#879440056ce94e1b
>
> That thread certainly makes the point about unbound forms not being
> required to create a good app in Access.
>
>> right now thats taking a long time to read :) I think it may boil
>> down to a decision as to weather the project is big enough to
>> warrent developing the data access layer....but clearly I need to
>> do more research....as those 3 things were the only I could think
>> of off the top of my head....
>
> I would vote against the data access layer. But, of course, I'm
> operating without first-hand information about the app.
>
> I think that many people from the C/S side of things overengineer
> their apps, and a separate data access layer to an app that is
> currently operating with a Jet back end sounds like complete
> overkill. If a data access layer is necessary, then the app couldn't
> work at all with a Jet back end.
>

You are quiet probably right here also, unfortunatly im out of my depth to
argue any different :(

John

Re: Migrating away from MS-Access

"(PeteCresswell)" wrote in message
news:br8lh3d0gfpdf7gmk8ph6fork9tniofrjm@4ax.com...
> Per NewsGuy:
>> I think
>>once we start having to do things like unbound forms and massive rewrites,
>>while it would still be quicker to go access, I dont consider vb.net to be
>>hugly more expensive.
>
> I keep hearing that from people who probably know, but for the
> one app that I took the time to develop in both VB6 and MS Access
> the ratio was somewhere between three and five to one (got it
> recorded somewhere... but can't recall exactly).
>

I guess I consider VB6 and .net a different kettle of fish, mainly cause
inheritence makes alot of things so much quicker to develop with...
Right now, in my feeble state of mind, id say 1:3
access:vb.net...........but im in no way qualified to state this, so I
probably shouldnt have written it...

> But based on the dollars billed by a large company's IT
> department when they replaced two of my MS Access apps with
> net-centric (I know for sure one was .Net... not sure about the
> other) I'd expect the .Net ratio tb more like 10:1.
>
> Been meaning to master enough of .Net to prove or disprove that
> suspicion for about five years now... but never got around to it.
>
> Maybe you can report back if/when you do it.
>
> Also... there are those who would argue that in the whole life
> cycle of an application, the initial development time is
> chickenfeed anyhow.
> --
> PeteCresswell

Yeah, I'd agree...200% agree....ya gotta admit though it is difficult to
appreciate that when ya got say 3 months of nobody seeing anything actually
work..."Whats that shy nerdy computer guy do all day, he just sits there and
types and types"....he *must* be crazy lol...

Re: Migrating away from MS-Access

"lyle fairfield" wrote in message
news:bhlSi.9049$xa2.7706@read2.cgocable.net...
> "NewsGuy" wrote in
> news:ffcgoc0fg3@news5.newsguy.com:
>
>> ugg, just realised my posting details have changed...I used to read as
>> "John" ...now im
>> "NewsGuy" wrote in message
>> news:ffcepe0d1n@news5.newsguy.com...
>>
>> Ive only just returned to this group after a few years absense, I
>> notice there is another guy called John...thats not me....:) I wonder
>> if thats confusing...
>>
>> Installed Vista on my home puta......yes, Im asking for more
>> pain....but so far.....mostly good....
>>
>> I guess I should mention that I do realise VB.net will take
>> longer....its a case of weather its worth it keeping in mind a large
>> system that it may one day grow into...
>>
>> I dunno, also no one really wants to work with access is the general
>> vibe I get...some people scoff at me when I tell them Im an access
>> developer...but yeah I guess only fools listen to fools....I wonder
>> how the employment market is for access developers and if/when we get
>> another if that has any merit for analysis...
>>
>> John
>
> In my opinion:
> - Most databases are crap, beginning with the original northwind sample
> from ms;
> - Most institutions assign database development and maintenance to
> someone inadequate;
> - Most upper-level managers do not understand the value of a
> comprehensive, well-designed, efficient database;
> - Many upper-level managers do not want a comprehensive, well-designed,
> efficient database because it can threaten their power to do whatever
> they want;
> - Many developers and sa's use system databases as a support for their
> own personal fiefdom;
> - Many developers and sa's use system databases inappropriately for their
> own personal enjoyment, aggrandizement or profit;
> - Security in most databases is a joke;
> - Many IT personnel have no background in programming yet feel fully
> qualified to evaluate Access and other technologies.
>
> Developers deal with these disagreeable facts every day. It's what we do!
> Making a few pretty Access forms and a couple of official looking Access
> reports is five per cent of our work. We get paid $80 or $100 per hour to
> deal get into the swamp and battle with the alligators. It's life.
>
> My last task yesterday was to figure out why we had one too many
> (distinct) site names in a table we imported from a excel workbook.
> Simple: the workbook had an Orchard #2 (one space) and an Orchard #2
> (two spaces). So I created a regular expression replace that grabbed only
> the Uppercase alpha-numeric characters from the excel school names and
> compared them.
> Then I was told our totals weren't the spreadsheet's total which were
> public and "official". Why? Well the spreadsheet showed integers but
> added decimals. Their totals were wrong? Maybe they are, depending upon
> your point of view and level of education. What to do? I referred that
> one to my contact. What shall we use? 10 + 10 + 10 = 31, or 10.3 + 10.3 +
> 10 .3 = 30.9 or 10 + 10 + 10 = 30. Oh simple, use the spreadsheet totals,
> right? Not so simple, we do f(10) and f(10) + f(10) + f(10) has to add up
> to f(their total); and the 10 is ten people, bodies; in the real world we
> simply don't have 31 bodies.
>
> These are no big deal, but such things are a big part of any developer's
> work.
>
> I am suggesting that you are not alone.
>
>
> --
> lyle fairfield

lol, sounds like ur in a lot of pain :) Sometimes I wonder why I'm in this
industry....rights now i feels ya man...

Re: Migrating away from MS-Access

What im actually considering now is as follows ;

Leave everything as it is for current users to use....

Start clean ;
1.Migrate the structure of the backend in SQL Server ; Cleaning and
documenting as I go...
2.That'll give me time to really properly analyse where to go with the front
end...(I hope)
3.Rewrite from scratch the front ends (migrating what can be salvaged)
4.Once its at a level near being able to supercede write a program to
migrate the data....

I think without doubt this is going to be the quickest safest way, but the
problem with that is the people that wanna see it working arnt going to see
any progress for a long time...when I put that to the boss, I'll be able to
tell if im in fairly land thinking this might be a way to go or not...

It *seams* like a good plan...
John

Re: Migrating away from MS-Access

This makes a lot of sense after a reread...

The table names have primary key's called "ID" for a good 75% of the tables
which presents a big problem with automated changes...urrggg...this makes me
consider a manual rewrite...

"David W. Fenton" wrote in message
news:Xns99CAAD811F97f99a49ed1d0c49c5bbb2@216.196.97.142...
> "John" wrote in
> news:fev6df01u8j@news4.newsguy.com:
>
>> 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...
>
> It's not you.
>
> If I were handed a project like this, the first thing I'd do would
> be refactoring everything to come up to my coding standards. That
> means changing no functionality at all, and just converting it to be
> done right. That would involve steps in this order:
>
> 1. use Speed Ferret to fix all the naming problems.
>
> 2. go through the code sub/function by sub/function and fix the
> formatting and naming conventions. Change *no* functionality at all.
>
> 3. fix the dependencies on other forms without changing
> functionality. That is, just make the most minimal changes to get
> rid of the dependencies and do it right.
>
> Obviously, step 1 involves both the front end and back end.
>
> The point here is to do something with the code that makes it better
> without actually changing what it does or how it works. The process
> of doing this will force you to become familiar with the application
> as it stands now, and will then enable you to understand what needs
> to be redesigned/replaced.
>
> Only after a refactoring would I then embark on trying to fix the
> design problems.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

On Oct 21, 4:32 am, "NewsGuy" wrote:
> "lyle fairfield" wrote in message
>
> news:bhlSi.9049$xa2.7706@read2.cgocable.net...
>
>
>
> > "NewsGuy" wrote in
> >news:ffcgoc0fg3@news5.newsguy.com:
>
> >> ugg, just realised my posting details have changed...I used to read as
> >> "John" ...now im
> >> "NewsGuy" wrote in message
> >>news:ffcepe0d1n@news5.newsguy.com...
>
> >> Ive only just returned to this group after a few years absense, I
> >> notice there is another guy called John...thats not me....:) I wonder
> >> if thats confusing...
>
> >> Installed Vista on my home puta......yes, Im asking for more
> >> pain....but so far.....mostly good....
>
> >> I guess I should mention that I do realise VB.net will take
> >> longer....its a case of weather its worth it keeping in mind a large
> >> system that it may one day grow into...
>
> >> I dunno, also no one really wants to work with access is the general
> >> vibe I get...some people scoff at me when I tell them Im an access
> >> developer...but yeah I guess only fools listen to fools....I wonder
> >> how the employment market is for access developers and if/when we get
> >> another if that has any merit for analysis...
>
> >> John
>
> > In my opinion:
> > - Most databases are crap, beginning with the original northwind sample
> > from ms;
> > - Most institutions assign database development and maintenance to
> > someone inadequate;
> > - Most upper-level managers do not understand the value of a
> > comprehensive, well-designed, efficient database;
> > - Many upper-level managers do not want a comprehensive, well-designed,
> > efficient database because it can threaten their power to do whatever
> > they want;
> > - Many developers and sa's use system databases as a support for their
> > own personal fiefdom;
> > - Many developers and sa's use system databases inappropriately for their
> > own personal enjoyment, aggrandizement or profit;
> > - Security in most databases is a joke;
> > - Many IT personnel have no background in programming yet feel fully
> > qualified to evaluate Access and other technologies.
>
> > Developers deal with these disagreeable facts every day. It's what we do!
> > Making a few pretty Access forms and a couple of official looking Access
> > reports is five per cent of our work. We get paid $80 or $100 per hour to
> > deal get into the swamp and battle with the alligators. It's life.
>
> > My last task yesterday was to figure out why we had one too many
> > (distinct) site names in a table we imported from a excel workbook.
> > Simple: the workbook had an Orchard #2 (one space) and an Orchard #2
> > (two spaces). So I created a regular expression replace that grabbed only
> > the Uppercase alpha-numeric characters from the excel school names and
> > compared them.
> > Then I was told our totals weren't the spreadsheet's total which were
> > public and "official". Why? Well the spreadsheet showed integers but
> > added decimals. Their totals were wrong? Maybe they are, depending upon
> > your point of view and level of education. What to do? I referred that
> > one to my contact. What shall we use? 10 + 10 + 10 = 31, or 10.3 + 10.3 +
> > 10 .3 = 30.9 or 10 + 10 + 10 = 30. Oh simple, use the spreadsheet totals,
> > right? Not so simple, we do f(10) and f(10) + f(10) + f(10) has to add up
> > to f(their total); and the 10 is ten people, bodies; in the real world we
> > simply don't have 31 bodies.
>
> > These are no big deal, but such things are a big part of any developer's
> > work.
>
> > I am suggesting that you are not alone.
>
> > --
> > lyle fairfield
>
> lol, sounds like ur in a lot of pain :) Sometimes I wonder why I'm in this
> industry....rights now i feels ya man...

I'm not in pain. The circumstances I described are quite common and I
am entirely familiar with them. I am in this business because I enjoy
the challenges and the intellectual stimulation, and my family enjoys
the money, and because my clients seem to be able to persuade me to
ignore my stated public status of "retired".
I don't find the circumstances that you describe unusual at all. In my
opinion they too are quite common.
If it's your job to deal with them then get on with it.

Re: Migrating away from MS-Access

Wow, what a discussion!

I have been developing in access for the last 15 years, not because
that's all I know but it is so easy to create fast useful
applications!
And yes I also develop with sql server and vb.net...
A good access developer can create a system in half the time of a .net
guy.
Even .net applications can be better prototyped in access first.

So, fix the structure and then port to .net if that is what you have
to do....

The biggest issues you see are:

Bad coding and bad database design.

Yes, move the backend to sql server but do this in a smart way.
Use stored procedures wherever you can and don't query huge
recordsets...e.g be smarter by filtering first!
Just read John Viescas's book on building access applications.

So you really need to do a current e-r plan and future e-r plan and
make the necessary steps to achieve it.

If your users mainly want reports, then do these with stored
procedures and reporting services...this reduces the complexity and
enables your users to get their information securely over the
internet....

You will never win against die hard .net coders until they get the
sack for taking so long and not delivering....

One of the biggest frustrations are pure developers who really don't
understand databases and how to get the most out of them which is
quite a large proportion. If that wasn't true, I wouldn't be so busy.

Bottom line, you need a database specialist, not a developer.......

Regards,
Tom Bizannes
Sydney, Australia

Re: Migrating away from MS-Access

lyle wrote:
> On Oct 21, 4:32 am, "NewsGuy" wrote:
>> "lyle fairfield" wrote in message

> I'm not in pain. The circumstances I described are quite common and I
> am entirely familiar with them. I am in this business because I enjoy
> the challenges and the intellectual stimulation, and my family enjoys
> the money, and because my clients seem to be able to persuade me to
> ignore my stated public status of "retired".

Here lies Lyle Fairfield, retired.

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:fff2ee02vk2@news3.newsguy.com:

> I guess I consider VB6 and .net a different kettle of fish, mainly
> cause inheritence makes alot of things so much quicker to develop
> with...

I think you over-rate the value of inheritance.

And in regard to the comparison to Access, VB and VB.NET are really
quite comparable in lacking Access's design that is specifically
architected for database applications.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

lyle wrote in
news:1192961929.372297.301820@y27g2000pre.googlegroups.com:

> The circumstances I described are quite common and I
> am entirely familiar with them. I am in this business because I
> enjoy the challenges and the intellectual stimulation, and my
> family enjoys the money, and because my clients seem to be able to
> persuade me to ignore my stated public status of "retired".
> I don't find the circumstances that you describe unusual at all.
> In my opinion they too are quite common.
> If it's your job to deal with them then get on with it.

I agree with Lyle on this. The things he describes are exactly what
I deal with all the time, and it's what I expect -- not because I
think the people I work for are stupid, but because I expect them to
not know the things someone with professional experience and
training like myself would know about the specifics of creating a
database application. I have good clients who have enough
self-knowledge to know that they lack knowledge that I have, and
they depend on me to steer them in the right direction.

But I *never* underrate their knowledge of their businesses, which
often trumps my database experience.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

Per David W. Fenton:
>I think you over-rate the value of inheritance.

I'm with David on this one - again.

The flip side of inheritance (as opposed to cloning) is that
if/when you change the object, you need tb *really* careful of
unforeseen consequences to the object's consumers.
--
PeteCresswell

Re: Migrating away from MS-Access

"NewsGuy" wrote:

>The table names have primary key's called "ID" for a good 75% of the tables
>which presents a big problem with automated changes...urrggg...this makes me
>consider a manual rewrite...

Could you expand on this a bit more?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Migrating away from MS-Access

NewsGuy wrote:

>
> I guess I consider VB6 and .net a different kettle of fish, mainly cause
> inheritence makes alot of things so much quicker to develop with...

Are you talking about customizing GUI widgets here or creating the data
layer that people have told you you don't need?

Re: Migrating away from MS-Access

"rkc" wrote in message
news:471bed37$0$28880$4c368faf@roadrunner.com...
> NewsGuy wrote:
>
>>
>> I guess I consider VB6 and .net a different kettle of fish, mainly cause
>> inheritence makes alot of things so much quicker to develop with...
>
> Are you talking about customizing GUI widgets here or creating the data
> layer that people have told you you don't need?

GUI...i find it quicker and more control...

Re: Migrating away from MS-Access

Well if I stick into speed ferret a search for ID it comes back with 1000+
changes which I have to be extreamly careful about as I cannot see them in
context....as alot of the times it is not prefixed like say tablename.ID

Thats with just a plain search, I see there are other kinds of searches in
speed ferret which I havent had a chance to thouroughly look into as there
may be a way to minimize that...

So I figure done manually if I migrate form by form, query by query into a
fresh database, maybe that might be the way to go...but still I gotta look
into automation before I go to that...but right now I cant think of a way to
get around the above problem...


"Tony Toews [MVP]" wrote in message
news:8hjnh3tppb6dvnahb3judkg26r3j1kgdcp@4ax.com...
> "NewsGuy" wrote:
>
>>The table names have primary key's called "ID" for a good 75% of the
>>tables
>>which presents a big problem with automated changes...urrggg...this makes
>>me
>>consider a manual rewrite...
>
> Could you expand on this a bit more?
>
> Tony
> --
> Tony Toews, Microsoft Access MVP
> Please respond only in the newsgroups so that others can
> read the entire thread of messages.
> Microsoft Access Links, Hints, Tips & Accounting Systems at
> http://www.granite.ab.ca/accsmstr.htm
> Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:ffhm8i02fmg@news3.newsguy.com:

> Well if I stick into speed ferret a search for ID it comes back
> with 1000+ changes which I have to be extreamly careful about as I
> cannot see them in context....as alot of the times it is not
> prefixed like say tablename.ID

What do you mean you can't see them in context? SQL strings are
fully viewable, while you see at least the line of code in modules.
Are there all that many references in code?

One solution would be this:

1. rename your linked tables to something else.

2. create a query with the name of each linked table.

3. in the query, include all fields, plus the ID field aliased by
the name it *should* have.

This will transparently allow you to convert all your forms/reports
as needed.

It would also allow you to rename the field in the base table and
then create an alias for ID.

Either way, it's a useful interim step while implementing this kind
of change.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

Not a bad idea...Cool thanks man...I will explore it..

I been a bit busy with critical bug fixes is why I havent had a chance to
have a good sticky beak into it....soon i hope

John

"David W. Fenton" wrote in message
news:Xns99D19EEA4D925f99a49ed1d0c49c5bbb2@216.196.97.142...
> "NewsGuy" wrote in
> news:ffhm8i02fmg@news3.newsguy.com:
>
>> Well if I stick into speed ferret a search for ID it comes back
>> with 1000+ changes which I have to be extreamly careful about as I
>> cannot see them in context....as alot of the times it is not
>> prefixed like say tablename.ID
>
> What do you mean you can't see them in context? SQL strings are
> fully viewable, while you see at least the line of code in modules.
> Are there all that many references in code?
>
> One solution would be this:
>
> 1. rename your linked tables to something else.
>
> 2. create a query with the name of each linked table.
>
> 3. in the query, include all fields, plus the ID field aliased by
> the name it *should* have.
>
> This will transparently allow you to convert all your forms/reports
> as needed.
>
> It would also allow you to rename the field in the base table and
> then create an alias for ID.
>
> Either way, it's a useful interim step while implementing this kind
> of change.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"(PeteCresswell)" wrote in message
news:1hgnh3heopq04und6f28eusfbr813cqrh6@4ax.com...
> Per David W. Fenton:
>>I think you over-rate the value of inheritance.
>
> I'm with David on this one - again.
>
> The flip side of inheritance (as opposed to cloning) is that
> if/when you change the object, you need tb *really* careful of
> unforeseen consequences to the object's consumers.
> --
> PeteCresswell

Yes, very true :)

I dunno, I guess ya can set up forms quiet easily that work just like access
minus the continuous forms....

Re: Migrating away from MS-Access

"SmartbizAustralia" wrote in message
news:1192968037.608409.9690@y27g2000pre.googlegroups.com...
> Wow, what a discussion!
>
> I have been developing in access for the last 15 years, not because
> that's all I know but it is so easy to create fast useful
> applications!
> And yes I also develop with sql server and vb.net...
> A good access developer can create a system in half the time of a .net
> guy.
> Even .net applications can be better prototyped in access first.
>
> So, fix the structure and then port to .net if that is what you have
> to do....
>
> The biggest issues you see are:
>
> Bad coding and bad database design.
>
> Yes, move the backend to sql server but do this in a smart way.
> Use stored procedures wherever you can and don't query huge
> recordsets...e.g be smarter by filtering first!
> Just read John Viescas's book on building access applications.
>
> So you really need to do a current e-r plan and future e-r plan and
> make the necessary steps to achieve it.
>
> If your users mainly want reports, then do these with stored
> procedures and reporting services...this reduces the complexity and
> enables your users to get their information securely over the
> internet....
>
> You will never win against die hard .net coders until they get the
> sack for taking so long and not delivering....
>
> One of the biggest frustrations are pure developers who really don't
> understand databases and how to get the most out of them which is
> quite a large proportion. If that wasn't true, I wouldn't be so busy.
>
> Bottom line, you need a database specialist, not a developer.......
>
> Regards,
> Tom Bizannes
> Sydney, Australia
>

Yeah you are right, one thing I notice about the old guy was he likes doing
the user interface but the backend is an afterthought...
You raised a few questions, which I beg to ask, im short on time at the
moment...I havent looked at reporting services before...the current vb.net
app thats attacheddoesnt use stored procedures its just hardcoded sql
statements.

Thanks Tom
John

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:ffj6820udd@news3.newsguy.com:

> I guess ya can set up forms quiet easily that work just like
> access minus the continuous forms....

No, you can't.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"NewsGuy" wrote:

>Well if I stick into speed ferret a search for ID it comes back with 1000+
>changes which I have to be extreamly careful about as I cannot see them in
>context....as alot of the times it is not prefixed like say tablename.ID

Oh, I see what you mean. Yeeyuck. I do *NOT* like duplicating field names between
tables although some do.

Tony's Table and Field Naming Conventions
http://www.granite.ab.ca/access/tablefieldnaming.htm
A few people like my idea. A few people are utterly horrified. Most people just
aren't quite sure about my sanity.

>So I figure done manually if I migrate form by form, query by query into a
>fresh database, maybe that might be the way to go...but still I gotta look
>into automation before I go to that...but right now I cant think of a way to
>get around the above problem...

I once accidently named a field on a table Inactive. 99% of the time I would've had
the initials of the table in their before the word Inactive but the table started
with an L so it was real easy to miss the l in front of Inactive. That was a PITA
to fix up correctly given how many fields in my database ending with Inactive.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Migrating away from MS-Access

I like some aspects of your naming conventions...

In the past I have not typically prefixed all fields with the initialised
table name, only the primary keys with the full table name with ID if it
happens to be a autonumber or CODE if it ends up being textual based (rarly
tho)...

But yeah I do repeat the fieldname if it is a foreign key, but I see the
merit of your approach, i might start doing that...

Im fond of tbl, qry, mod, etc perfixes too...

....and I often name things that logically read backwards just so they line
up neatly into groups when alphabetised, im not sure if thats hard for
others to read, but I find it easier like that...

After a few important things for the most part I guess consistancy is what
counts

Thats all a whole new thread for that discussion im sure :)
John


"Tony Toews [MVP]" wrote in message
news:m1bth39h5j5m2l3utgu4ahnipqtf2i8jpl@4ax.com...
> "NewsGuy" wrote:
>
>>Well if I stick into speed ferret a search for ID it comes back with 1000+
>>changes which I have to be extreamly careful about as I cannot see them in
>>context....as alot of the times it is not prefixed like say tablename.ID
>
> Oh, I see what you mean. Yeeyuck. I do *NOT* like duplicating field
> names between
> tables although some do.
>
> Tony's Table and Field Naming Conventions
> http://www.granite.ab.ca/access/tablefieldnaming.htm
> A few people like my idea. A few people are utterly horrified. Most
> people just
> aren't quite sure about my sanity.
>
>>So I figure done manually if I migrate form by form, query by query into a
>>fresh database, maybe that might be the way to go...but still I gotta look
>>into automation before I go to that...but right now I cant think of a way
>>to
>>get around the above problem...
>
> I once accidently named a field on a table Inactive. 99% of the time I
> would've had
> the initials of the table in their before the word Inactive but the table
> started
> with an L so it was real easy to miss the l in front of Inactive. That
> was a PITA
> to fix up correctly given how many fields in my database ending with
> Inactive.
>
> Tony
> --
> Tony Toews, Microsoft Access MVP
> Please respond only in the newsgroups so that others can
> read the entire thread of messages.
> Microsoft Access Links, Hints, Tips & Accounting Systems at
> http://www.granite.ab.ca/accsmstr.htm
> Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Migrating away from MS-Access

I guess its not as easy, but easily is a subjective term...

I havent actually done it so, I guess I should shut my gob :) It doesnt seam
to me like to hard a thing to do...(Ive been wrong about,
'seams easy' more times than not tho:) )

Continuous forms for mine are the huge time savers in access....well amongst
other things....

Depending on where we go...I may know soon enough...

John

"David W. Fenton" wrote in message
news:Xns99D2679AF2617f99a49ed1d0c49c5bbb2@216.196.97.142...
> "NewsGuy" wrote in
> news:ffj6820udd@news3.newsguy.com:
>
>> I guess ya can set up forms quiet easily that work just like
>> access minus the continuous forms....
>
> No, you can't.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"NewsGuy" wrote:

>Im fond of tbl, qry, mod, etc perfixes too...

I'm not. Tony's Object Naming Conventions
http://www.granite.ab.ca/access/tonysobjectnamingconventions .htm

Using tbl, qry, frm, rpt really, really slows me down when working in a database.

>...and I often name things that logically read backwards just so they line
>up neatly into groups when alphabetised, im not sure if thats hard for
>others to read, but I find it easier like that...

In larger systems I will use PO for purchasing, Inv for inventory, QC for Quality
Control and such.

>Thats all a whole new thread for that discussion im sure :)
>John

Oh yeah!

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:ffpivt030t3@news5.newsguy.com:

> I havent actually done it so, I guess I should shut my gob :) It
> doesnt seam to me like to hard a thing to do

Well, if all your Access work is extremely trivial point and click
work with no use of the rich event model, you would find it easy to
recreate in another development environment. But once you become
dependent on the Access event model, the other products become much
more complex to work (as do unbound forms in Access itself).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

>
>> I havent actually done it so, I guess I should shut my gob :) It
>> doesnt seam to me like to hard a thing to do
>
> Well, if all your Access work is extremely trivial point and click
> work with no use of the rich event model, you would find it easy to
> recreate in another development environment. But once you become
> dependent on the Access event model, the other products become much
> more complex to work (as do unbound forms in Access itself).
>

I dunno if I agree with that...binding controls to a dataset is pretty
straight forward, and I dont really see how its much different, I see all
the extra work in saving the dataset and all that stuff...

Hmm actually I can sorta see what you are getting at...but im not entirly
sure...I clearly need to know more :) This is my first database driven
project in dotnet if we do indeed go that way (apart from uni
assignments)...

I've come to the conclusion the project needs a rewrite from scratch using
the old one as a template for requirements, im not sure that even trying to
tidy up the old version would be worth it as the database strucuture is just
too conviluted...

I think I need to take a chill pill on discussion of vb.net vs access while
I do more research...

Has anyone ever tried a cross post to a vb.net newgroup? is that frowned
upon? I'd imagine it'd turn into a nasty brawl :)

John

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:ffs7vj0bqn@news1.newsguy.com:

>>> I havent actually done it so, I guess I should shut my gob :) It
>>> doesnt seam to me like to hard a thing to do
>>
>> Well, if all your Access work is extremely trivial point and
>> click work with no use of the rich event model, you would find it
>> easy to recreate in another development environment. But once you
>> become dependent on the Access event model, the other products
>> become much more complex to work (as do unbound forms in Access
>> itself).
>
> I dunno if I agree with that...binding controls to a dataset is
> pretty straight forward, and I dont really see how its much
> different, I see all the extra work in saving the dataset and all
> that stuff...

The fact that you reduce what I said to "binding controls to a
dataset" shows that you don't really use Access except trivially.

> Hmm actually I can sorta see what you are getting at...but im not
> entirly sure...I clearly need to know more :) This is my first
> database driven project in dotnet if we do indeed go that way
> (apart from uni assignments)...

What does a data-bound .NET form offer to replace the BeforeUpdate
and AfterUpdate events of the form? Do you have to write your own
code? Or does it have default events for that that can be altered as
needed?

> I've come to the conclusion the project needs a rewrite from
> scratch using the old one as a template for requirements, im not
> sure that even trying to tidy up the old version would be worth it
> as the database strucuture is just too conviluted...

You mean the back end? That will have to be cleaned up either way,
won't it? It's very hard to build a good app on top of a badly
structured database, no matter what development tools you're using.

> I think I need to take a chill pill on discussion of vb.net vs
> access while I do more research...

As much in Access as VB.NET, I'd say.

> Has anyone ever tried a cross post to a vb.net newgroup? is that
> frowned upon? I'd imagine it'd turn into a nasty brawl :)

Most of the .NET people don't understand Access, so I would *not*
appreciate your dragging them into our newsgroup.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

Per NewsGuy:
>I think I need to take a chill pill on discussion of vb.net vs access while
>I do more research...

From a purely parochial perspective, if you learn VB.net, you'll
be gaining a more widely-used skill set for developers than with
MS Access.

--
PeteCresswell

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99D5C01BAA7F5f99a49ed1d0c49c5bbb2@216.196.97.142...
> "NewsGuy" wrote in
> news:ffs7vj0bqn@news1.newsguy.com:
>
>>>> I havent actually done it so, I guess I should shut my gob :) It
>>>> doesnt seam to me like to hard a thing to do
>>>
>>> Well, if all your Access work is extremely trivial point and
>>> click work with no use of the rich event model, you would find it
>>> easy to recreate in another development environment. But once you
>>> become dependent on the Access event model, the other products
>>> become much more complex to work (as do unbound forms in Access
>>> itself).
>>
>> I dunno if I agree with that...binding controls to a dataset is
>> pretty straight forward, and I dont really see how its much
>> different, I see all the extra work in saving the dataset and all
>> that stuff...
>
> The fact that you reduce what I said to "binding controls to a
> dataset" shows that you don't really use Access except trivially.
>
>> Hmm actually I can sorta see what you are getting at...but im not
>> entirly sure...I clearly need to know more :) This is my first
>> database driven project in dotnet if we do indeed go that way
>> (apart from uni assignments)...
>
> What does a data-bound .NET form offer to replace the BeforeUpdate
> and AfterUpdate events of the form? Do you have to write your own
> code? Or does it have default events for that that can be altered as
> needed?
>

I guess we'd have to write our own code, which I guess is no biggie for
simple stuff...but it wont all be simple...

What kind of instances would you use BeforeUpdate and AfterUpdates for? Why
do I feel like a noob asking that :) Maybe I am! Hmm nah my memory has
somewhat faded...

>> I've come to the conclusion the project needs a rewrite from
>> scratch using the old one as a template for requirements, im not
>> sure that even trying to tidy up the old version would be worth it
>> as the database strucuture is just too conviluted...
>
> You mean the back end? That will have to be cleaned up either way,
> won't it? It's very hard to build a good app on top of a badly
> structured database, no matter what development tools you're using.
>

Yeah, sorry thats what I meant, was not related to this part of thread, more
the overall thread...I've given up on trying to tidy it, rewrite is the
go...

>> I think I need to take a chill pill on discussion of vb.net vs
>> access while I do more research...
>
> As much in Access as VB.NET, I'd say.
>

Quiet Possibly, I guess I've only really worked on the one fairly large
access application which i spent 3 or 4 years doing but I never really
encountered any major problems. Maybe I dont know as much about access as I
thought I did...

>> Has anyone ever tried a cross post to a vb.net newgroup? is that
>> frowned upon? I'd imagine it'd turn into a nasty brawl :)
>
> Most of the .NET people don't understand Access, so I would *not*
> appreciate your dragging them into our newsgroup.
>

Yeah, I could invisage that being the case...:) Its pretty hard to be a guru
at both I suppose...

Re: Migrating away from MS-Access

"(PeteCresswell)" wrote in message
news:ovt4i3tq6ulq5p5bv5f0q39o06sj7efm6v@4ax.com...
> Per NewsGuy:
>>I think I need to take a chill pill on discussion of vb.net vs access
>>while
>>I do more research...
>
> From a purely parochial perspective, if you learn VB.net, you'll
> be gaining a more widely-used skill set for developers than with
> MS Access.
>

Yeah, 90% of places want VB.Net, I rarly see MS-Access jobs....although my
Access experience got me this one..

It'd be nice if micrsoft made access into a full on development environment
with easier methods of deployment...I guess they dont really want that
though, they want people to go to dotnet..

John

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:ffuqt202cj9@news4.newsguy.com:

> What kind of instances would you use BeforeUpdate and AfterUpdates
> for? Why do I feel like a noob asking that :) Maybe I am! Hmm nah
> my memory has somewhat faded...

BeforeUpdate, at the form or control level, allows you to validate
data before it is saved and inform the user that there's a problem.
This is crucial in avoiding tying up the server with the validation.

AfterUpdate is essential for doing actions after the update is
completed. For example, you might want to requery another open form
or rowsource-bearing control in the AfterUpdate event.

These are essential events for all database programming, and you
don't have to do anything but write the code specific to your app
when using Access. With .NET, you have to do it all yourself, right?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:ffur8h02d1v@news4.newsguy.com:

> It'd be nice if micrsoft made access into a full on development
> environment with easier methods of deployment...I guess they dont
> really want that though, they want people to go to dotnet..

What problems do you have with Access deployment?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

Per David W. Fenton:
>What problems do you have with Access deployment?

Biggest one I see is the prospect of a new release of MS Access
breaking my apps - however briefly.

Next biggest is IT's aversion to MS Access - however unfounded
and based on a faulty understanding of what MS Access is.
--
PeteCresswell

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2@216.196.97.142...
> "NewsGuy" wrote in
> news:ffur8h02d1v@news4.newsguy.com:
>
>> It'd be nice if micrsoft made access into a full on development
>> environment with easier methods of deployment...I guess they dont
>> really want that though, they want people to go to dotnet..
>
> What problems do you have with Access deployment?
>

Well I dont have any really, and I have never done it, but a long time ago I
researched it and only ever read bad things, my brother did it once and I
believe he had nothin but trouble...

At current for this project it would be unnecessary to deploy it...

I was discussing with the old guy today, he said that PDF's via terminal
services are chugging things up (We have alot of PDF's attached)....weather
thats a reason for deployment I dont know...Im unsure if downloading the PDF
would be quicker than going term services...apparently users like to click
the scrolls up and down alot, and that chugs it.....i know thats been
discussed earlier in this thread, all I can go on is his word at this
stage...

My feeling is he is probably right...so I might have to look at
deployment...I am unsure....

John

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99D6B3A7C33A2f99a49ed1d0c49c5bbb2@216.196.97.142...
> "NewsGuy" wrote in
> news:ffuqt202cj9@news4.newsguy.com:
>
>> What kind of instances would you use BeforeUpdate and AfterUpdates
>> for? Why do I feel like a noob asking that :) Maybe I am! Hmm nah
>> my memory has somewhat faded...
>
> BeforeUpdate, at the form or control level, allows you to validate
> data before it is saved and inform the user that there's a problem.
> This is crucial in avoiding tying up the server with the validation.
>
> AfterUpdate is essential for doing actions after the update is
> completed. For example, you might want to requery another open form
> or rowsource-bearing control in the AfterUpdate event.
>
> These are essential events for all database programming, and you
> don't have to do anything but write the code specific to your app
> when using Access. With .NET, you have to do it all yourself, right?
>

Ahh ok..good explanation, makes sense...You;d think id be familiar with
that....thinking back I hardly even remember how I did validation in my old
project...

Yeah, In terms of doing the validation with .net....I just have a validation
procedure that I set to handle the onValidating event of every control on a
form which i find works well and is very easy...Im yet to do complicated
validation tho, I have not tried it with datagrids...sooo..... :) yeah id
imagine it will get rather complicated...

We have developer express components which have been heavily used. We use
their DXerrorProvider, which is kinda cool.......as for that whole
toolset....its chuggy, has a gazillion properties, methods....it looks
pretty...:) Might take me 2 years to learn how to use it
all....haha...yer....it doesnt sound good...in the beginning I spent alot of
time just familiarising with these tools...I dont think theyre a good
idea...but I guess thats a gaping hole showing my inexperience....shoulda
looked at the backend straight away...

I did manage to convince the old guy that dotnet is gonna take alot longer,
but its the boss who will have to make the decision. Old guy is still hell
bent on proceeding along his original path tho...

One good thing about dotnet is that when ya change a dataset column name, it
immediatly shows everywhere that needs to be fixed...Thats the quickest most
reliable way of tidying badly named tables/fields (better than
speedferreting access).....but hmm thats a nonissue really...thats just
something i learned today..

John

Re: Migrating away from MS-Access

"(PeteCresswell)" wrote in message
news:pag7i3ha56nvfanl2t5k09aof5m46amag2@4ax.com...
> Per David W. Fenton:
>>What problems do you have with Access deployment?
>
> Biggest one I see is the prospect of a new release of MS Access
> breaking my apps - however briefly.
>
> Next biggest is IT's aversion to MS Access - however unfounded
> and based on a faulty understanding of what MS Access is.
> --
> PeteCresswell

I think the aversion comes because there ARE limits on access.....there is
no limit on .NET, if it cant be done in .NET then ya probably cant do
it....well except for time....:)

Quiet probably a naive comment...but I guess coming from a naive perspective
is generally what most people think like....

John

Re: Migrating away from MS-Access

Per NewsGuy:
>I think the aversion comes because there ARE limits on access.....there is
>no limit on .NET, if it cant be done in .NET then ya probably cant do
>it....well except for time....:)

My experience is that IT views MS Access applications and the JET
database back end as one and the same: basically a toy and not
suitable for any serious development. What they usually fail
to grasp is that "MS Access" is really a front end development
tool analogous to VB6 or VB.Net or PowerBuilder and the JET back
end is just one of many back ends that it can connect to.

I see a number of legitimate limitations on the use of MS Access
as a front end development tool - but the IT people I've known
who object to MS Access are not thinking of them; they're just
focused on the incorrect notion that a JET back end is part of
the deal for all MS Access apps.

Most of the reasons I tend to think of are "horses for courses"
kinds of things. Not ironclad reasons to avoid MS Access front
ends; but rather tradeoffs that one has to consider.

BTW this is from somebody who can't even do "Hello World" in
VB.net.
--
PeteCresswell

Re: Migrating away from MS-Access

(PeteCresswell) wrote:
> Per NewsGuy:
> > I think the aversion comes because there ARE limits on
> > access.....there is no limit on .NET, if it cant be done in .NET
> > then ya probably cant do it....well except for time....:)
>
> My experience is that IT views MS Access applications and the JET
> database back end as one and the same: basically a toy and not
> suitable for any serious development. What they usually fail
> to grasp is that "MS Access" is really a front end development
> tool analogous to VB6 or VB.Net or PowerBuilder and the JET back
> end is just one of many back ends that it can connect to.
[snip]

An even bigger problem is that "real" programmers that use "real" programming
languages and development tools have that attitude about Access and they are the
very people who are creating each new version.

That is the reason for Access' perpetual slide toward a power user tool with no
emphasis on serious development. Because the people who create Access are not
the people who would ever use it.

As for the original topic there are a number of reasons why specific development
tools and technologies are chosen. Common sense would dictate that those that
produce the fastest results that accomplish the required tasks for the least
cost would almost always be the ones chosen. Reality indicates otherwise.

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

Re: Migrating away from MS-Access

Per Rick Brandt:
>Common sense would dictate that those that
>produce the fastest results that accomplish the required tasks for the least
>cost would almost always be the ones chosen. Reality indicates otherwise.

I've heard it argued that the initial programming cost of a
system is only a small fraction of it's lifetime cost.

Don't know enough to judge that assertion - but it was being made
by people that management held in high regard.

I used to think that my target market was people who wanted the
most bang for the buck.

But now I've come around to believing that my real appeal is
being able to deliver a system that:
------------------------------------------------------------ -----
1) Didn't require a lot of front-end time from the users.

2) Can be readily evolved as users discover their real needs
(without going before a committee...)

3) Can be delivered as release 1.0 - no matter how
rudimentary - within a certain calendar timeframe.
------------------------------------------------------------ ------

That's not to say that my hours billed are insignificant to the
clients... however the guys I'm doing a system for right now are
using me as an alternative to a 2.5 million dollar off-the-shelf
bond trading system... and if I ever bill more than 70k for this
thing I will be surprised....

So I wouldn't expect it tb a big deal to them if it took me three
or even five or six times the man hours to create the system
because I believe that what they *really* want is for Pete to
figure out the details of what they need; provide same without
their having to sign a thousand pages of specs in blood; and
evolve the system as needed with the least pain possible..
--
PeteCresswell

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:fg1k6202hpu@news1.newsguy.com:

> I think the aversion comes because there ARE limits on
> access.....there is no limit on .NET, if it cant be done in .NET
> then ya probably cant do it....well except for time....:)
>
> Quiet probably a naive comment...but I guess coming from a naive
> perspective is generally what most people think like...

The difference is only between a specialized tool tuned for a
specific task and a general tool that is usable for any task. Access
has all these database-specific features that have to be
custom-built in .NET (or implemented using add-in classes). It's
designed for one purpose, and it's really unequalled at that task in
terms of suitability to purpose and speed of development.

Granted, you wouldn't use it to program a word processor.

But that would just show stupidity in not choosing the right tool.

I have yet to see an objection to Access-as-front-end that is both a
true drawback of Access and not also easily resolvable in some
fashion. Most of the objections are from those who are simply
ignorant.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:fg1hj802cks@news1.newsguy.com:

> "David W. Fenton" wrote in message
> news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2@216.196.97.142...
>> "NewsGuy" wrote in
>> news:ffur8h02d1v@news4.newsguy.com:
>>
>>> It'd be nice if micrsoft made access into a full on development
>>> environment with easier methods of deployment...I guess they
>>> dont really want that though, they want people to go to dotnet..
>>
>> What problems do you have with Access deployment?
>
> Well I dont have any really, and I have never done it, but a long
> time ago I researched it and only ever read bad things, my brother
> did it once and I believe he had nothin but trouble...

I suggest that you do some investigation before making
recommendations on the basis of your hazy emotions about Access
deployment.

> At current for this project it would be unnecessary to deploy
> it...
>
> I was discussing with the old guy today, he said that PDF's via
> terminal services are chugging things up (We have alot of PDF's
> attached)....weather thats a reason for deployment I dont
> know...Im unsure if downloading the PDF would be quicker than
> going term services...apparently users like to click the scrolls
> up and down alot, and that chugs it.....i know thats been
> discussed earlier in this thread, all I can go on is his word at
> this stage...
>
> My feeling is he is probably right...so I might have to look at
> deployment...I am unsure....

I really don't see that this has anything at all to do with Access
deployment, since it's an outside issue entirely.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"Rick Brandt" wrote:

>As for the original topic there are a number of reasons why specific development
>tools and technologies are chosen. Common sense would dictate that those that
>produce the fastest results that accomplish the required tasks for the least
>cost would almost always be the ones chosen. Reality indicates otherwise.

IT managers are generally clueless about the details of the technologies and have
drunk the koolaid of all the articles and such.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99D790D8E32A4f99a49ed1d0c49c5bbb2@216.196.97.142...
> "NewsGuy" wrote in
> news:fg1hj802cks@news1.newsguy.com:
>
>> "David W. Fenton" wrote in message
>> news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2@216.196.97.142...
>>> "NewsGuy" wrote in
>>> news:ffur8h02d1v@news4.newsguy.com:
>>>
>>>> It'd be nice if micrsoft made access into a full on development
>>>> environment with easier methods of deployment...I guess they
>>>> dont really want that though, they want people to go to dotnet..
>>>
>>> What problems do you have with Access deployment?
>>
>> Well I dont have any really, and I have never done it, but a long
>> time ago I researched it and only ever read bad things, my brother
>> did it once and I believe he had nothin but trouble...
>
> I suggest that you do some investigation before making
> recommendations on the basis of your hazy emotions about Access
> deployment.
>
>> At current for this project it would be unnecessary to deploy
>> it...
>>
>> I was discussing with the old guy today, he said that PDF's via
>> terminal services are chugging things up (We have alot of PDF's
>> attached)....weather thats a reason for deployment I dont
>> know...Im unsure if downloading the PDF would be quicker than
>> going term services...apparently users like to click the scrolls
>> up and down alot, and that chugs it.....i know thats been
>> discussed earlier in this thread, all I can go on is his word at
>> this stage...
>>
>> My feeling is he is probably right...so I might have to look at
>> deployment...I am unsure....
>
> I really don't see that this has anything at all to do with Access
> deployment, since it's an outside issue entirely.
>

Well as soon as we deploy it outside of terminal services we'd be running
through a VPN, with sometimes poor/unreliable connections...I guess JET wont
handle that but I suppose itd be feasable with SQL Server?

John

Re: Migrating away from MS-Access

On Oct 29, 3:50 am, "NewsGuy" wrote:
> "David W. Fenton" wrote in messagenews:Xns99D790D8E32A4f99a49ed1d0c49c5bbb2@216.196.97. 142...
>
>
>
> > "NewsGuy" wrote in
> >news:fg1hj802cks@news1.newsguy.com:
>
> >> "David W. Fenton" wrote in message
> >>news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2@216.196.97.142.. .
> >>> "NewsGuy" wrote in
> >>>news:ffur8h02d1v@news4.newsguy.com:
>
> >>>> It'd be nice if micrsoft made access into a full on development
> >>>> environment with easier methods of deployment...I guess they
> >>>> dont really want that though, they want people to go to dotnet..
>
> >>> What problems do you have with Access deployment?
>
> >> Well I dont have any really, and I have never done it, but a long
> >> time ago I researched it and only ever read bad things, my brother
> >> did it once and I believe he had nothin but trouble...
>
> > I suggest that you do some investigation before making
> > recommendations on the basis of your hazy emotions about Access
> > deployment.
>
> >> At current for this project it would be unnecessary to deploy
> >> it...
>
> >> I was discussing with the old guy today, he said that PDF's via
> >> terminal services are chugging things up (We have alot of PDF's
> >> attached)....weather thats a reason for deployment I dont
> >> know...Im unsure if downloading the PDF would be quicker than
> >> going term services...apparently users like to click the scrolls
> >> up and down alot, and that chugs it.....i know thats been
> >> discussed earlier in this thread, all I can go on is his word at
> >> this stage...
>
> >> My feeling is he is probably right...so I might have to look at
> >> deployment...I am unsure....
>
> > I really don't see that this has anything at all to do with Access
> > deployment, since it's an outside issue entirely.
>
> Well as soon as we deploy it outside of terminal services we'd be running
> through a VPN, with sometimes poor/unreliable connections...I guess JET wont
> handle that but I suppose itd be feasable with SQL Server?
>
> John

I suggest that you convert to JDBC and SQLite with a GLOM front end on
Linux boxes.

Advantages?

To you:
A completely fresh start with technologies about which you are more
knowledgeable.

To me:
This thread is transferred to another newsgroup.
No more "old guy" pejoratives.

Re: Migrating away from MS-Access

"lyle" wrote in message
news:1193656936.789773.326910@19g2000hsx.googlegroups.com...
> On Oct 29, 3:50 am, "NewsGuy" wrote:
>> "David W. Fenton" wrote in
>> messagenews:Xns99D790D8E32A4f99a49ed1d0c49c5bbb2@216.196.97. 142...
>>
>>
>>
>> > "NewsGuy" wrote in
>> >news:fg1hj802cks@news1.newsguy.com:
>>
>> >> "David W. Fenton" wrote in message
>> >>news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2@216.196.97.142.. .
>> >>> "NewsGuy" wrote in
>> >>>news:ffur8h02d1v@news4.newsguy.com:
>>
>> >>>> It'd be nice if micrsoft made access into a full on development
>> >>>> environment with easier methods of deployment...I guess they
>> >>>> dont really want that though, they want people to go to dotnet..
>>
>> >>> What problems do you have with Access deployment?
>>
>> >> Well I dont have any really, and I have never done it, but a long
>> >> time ago I researched it and only ever read bad things, my brother
>> >> did it once and I believe he had nothin but trouble...
>>
>> > I suggest that you do some investigation before making
>> > recommendations on the basis of your hazy emotions about Access
>> > deployment.
>>
>> >> At current for this project it would be unnecessary to deploy
>> >> it...
>>
>> >> I was discussing with the old guy today, he said that PDF's via
>> >> terminal services are chugging things up (We have alot of PDF's
>> >> attached)....weather thats a reason for deployment I dont
>> >> know...Im unsure if downloading the PDF would be quicker than
>> >> going term services...apparently users like to click the scrolls
>> >> up and down alot, and that chugs it.....i know thats been
>> >> discussed earlier in this thread, all I can go on is his word at
>> >> this stage...
>>
>> >> My feeling is he is probably right...so I might have to look at
>> >> deployment...I am unsure....
>>
>> > I really don't see that this has anything at all to do with Access
>> > deployment, since it's an outside issue entirely.
>>
>> Well as soon as we deploy it outside of terminal services we'd be running
>> through a VPN, with sometimes poor/unreliable connections...I guess JET
>> wont
>> handle that but I suppose itd be feasable with SQL Server?
>>
>> John
>
> I suggest that you convert to JDBC and SQLite with a GLOM front end on
> Linux boxes.
>
> Advantages?
>
> To you:
> A completely fresh start with technologies about which you are more
> knowledgeable.
>
> To me:
> This thread is transferred to another newsgroup.
> No more "old guy" pejoratives.
>

I dunno if there is as helpful people in GLOM newsgroups...

I apologies for the "old guy" pejoratives, I didn't think I was doing that
too bad after the first few posts, but perhaps I am...
John

Re: Migrating away from MS-Access

"NewsGuy" wrote in
news:fg43am0qdp@news5.newsguy.com:

>
> "David W. Fenton" wrote in message
> news:Xns99D790D8E32A4f99a49ed1d0c49c5bbb2@216.196.97.142...
>> "NewsGuy" wrote in
>> news:fg1hj802cks@news1.newsguy.com:
>>
>>> "David W. Fenton" wrote in
>>> message
>>> news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2@216.196.97.142...
>>>> "NewsGuy" wrote in
>>>> news:ffur8h02d1v@news4.newsguy.com:
>>>>
>>>>> It'd be nice if micrsoft made access into a full on
>>>>> development environment with easier methods of deployment...I
>>>>> guess they dont really want that though, they want people to
>>>>> go to dotnet..
>>>>
>>>> What problems do you have with Access deployment?
>>>
>>> Well I dont have any really, and I have never done it, but a
>>> long time ago I researched it and only ever read bad things, my
>>> brother did it once and I believe he had nothin but trouble...
>>
>> I suggest that you do some investigation before making
>> recommendations on the basis of your hazy emotions about Access
>> deployment.
>>
>>> At current for this project it would be unnecessary to deploy
>>> it...
>>>
>>> I was discussing with the old guy today, he said that PDF's via
>>> terminal services are chugging things up (We have alot of PDF's
>>> attached)....weather thats a reason for deployment I dont
>>> know...Im unsure if downloading the PDF would be quicker than
>>> going term services...apparently users like to click the scrolls
>>> up and down alot, and that chugs it.....i know thats been
>>> discussed earlier in this thread, all I can go on is his word at
>>> this stage...
>>>
>>> My feeling is he is probably right...so I might have to look at
>>> deployment...I am unsure....
>>
>> I really don't see that this has anything at all to do with
>> Access deployment, since it's an outside issue entirely.
>>
>
> Well as soon as we deploy it outside of terminal services we'd be
> running through a VPN, with sometimes poor/unreliable
> connections...I guess JET wont handle that but I suppose itd be
> feasable with SQL Server?

Yes, of course. Everyone has told you repeatedly that much of the
problem with the app as you've described it would be best addressed
with a more appropriate back end. Jet can't be used across a WAN,
and anyone with any competence at all in Access would know that.

This is not an *Access* deployment issue -- it's a matter of
choosing the appropriate back end for the app and its deployment
requirements. If WTS isn't working, and you're blocked from other
avenues by the Jet back end, then it's pretty clear that someone
made some bad design decisions somewhere along the line.

But it still isn't an Access deployment issue.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: Migrating away from MS-Access

"David W. Fenton" wrote in message
news:Xns99D8A70358D04f99a49ed1d0c49c5bbb2@216.196.97.142...
> "NewsGuy" wrote in
> news:fg43am0qdp@news5.newsguy.com:
>
>>
>> "David W. Fenton" wrote in message
>> news:Xns99D790D8E32A4f99a49ed1d0c49c5bbb2@216.196.97.142...
>>> "NewsGuy" wrote in
>>> news:fg1hj802cks@news1.newsguy.com:
>>>
>>>> "David W. Fenton" wrote in
>>>> message
>>>> news:Xns99D6B3C368B62f99a49ed1d0c49c5bbb2@216.196.97.142...
>>>>> "NewsGuy" wrote in
>>>>> news:ffur8h02d1v@news4.newsguy.com:
>>>>>
>>>>>> It'd be nice if micrsoft made access into a full on
>>>>>> development environment with easier methods of deployment...I
>>>>>> guess they dont really want that though, they want people to
>>>>>> go to dotnet..
>>>>>
>>>>> What problems do you have with Access deployment?
>>>>
>>>> Well I dont have any really, and I have never done it, but a
>>>> long time ago I researched it and only ever read bad things, my
>>>> brother did it once and I believe he had nothin but trouble...
>>>
>>> I suggest that you do some investigation before making
>>> recommendations on the basis of your hazy emotions about Access
>>> deployment.
>>>
>>>> At current for this project it would be unnecessary to deploy
>>>> it...
>>>>
>>>> I was discussing with the old guy today, he said that PDF's via
>>>> terminal services are chugging things up (We have alot of PDF's
>>>> attached)....weather thats a reason for deployment I dont
>>>> know...Im unsure if downloading the PDF would be quicker than
>>>> going term services...apparently users like to click the scrolls
>>>> up and down alot, and that chugs it.....i know thats been
>>>> discussed earlier in this thread, all I can go on is his word at
>>>> this stage...
>>>>
>>>> My feeling is he is probably right...so I might have to look at
>>>> deployment...I am unsure....
>>>
>>> I really don't see that this has anything at all to do with
>>> Access deployment, since it's an outside issue entirely.
>>>
>>
>> Well as soon as we deploy it outside of terminal services we'd be
>> running through a VPN, with sometimes poor/unreliable
>> connections...I guess JET wont handle that but I suppose itd be
>> feasable with SQL Server?
>
> Yes, of course. Everyone has told you repeatedly that much of the
> problem with the app as you've described it would be best addressed
> with a more appropriate back end. Jet can't be used across a WAN,
> and anyone with any competence at all in Access would know that.
>
> This is not an *Access* deployment issue -- it's a matter of
> choosing the appropriate back end for the app and its deployment
> requirements. If WTS isn't working, and you're blocked from other
> avenues by the Jet back end, then it's pretty clear that someone
> made some bad design decisions somewhere along the line.
>
> But it still isn't an Access deployment issue.
>

Yeah I realise that JET wont do wan, I guess I meant to say we need to break
away from terminal services, and was asking if sqlserver would do ok with
access deployed...which in retrospect is a stupid question and to boot wasnt
worded very well at all...

Thanks for spending your time on me..
John

Re: Migrating away from MS-Access

Per David W. Fenton:
> Jet can't be used across a WAN,

Where does LAN end and WAN begin?

I'm thinking of a multi-building campus...
--
PeteCresswell

Re: Migrating away from MS-Access

"(PeteCresswell)" wrote in message
news:k0qci3t61qnu5s1a5qq5rkkm4eg0icrs36@4ax.com...
> Per David W. Fenton:
>> Jet can't be used across a WAN,
>
> Where does LAN end and WAN begin?
>
> I'm thinking of a multi-building campus...
> --
> PeteCresswell

Well I guess thats semantics, probably woulda better been said, fucked
connection, fucked backend...:)

For us it wont run is the bottom line, no hope in hell.....It's regional
Australia, so we are talking large distances some with substandard
connections..

I spose Id call a WAN one that uses external communication links that arnt
under the control of internal staff...

John

Re: Migrating away from MS-Access

"(PeteCresswell)" wrote in
news:k0qci3t61qnu5s1a5qq5rkkm4eg0icrs36@4ax.com:

> Per David W. Fenton:
>> Jet can't be used across a WAN,
>
> Where does LAN end and WAN begin?
>
> I'm thinking of a multi-building campus...

When bandwidth drops beneath 10Mbps, or when it switches from wired
to wireless.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/