Re: ADP Applications

"Rich P" <rpng123@xxxxxxx> wrote in message <45039d3f$0$34077$815e3792@xxxxxxxxxxxxxx>:

I wonder in which world you've found the experience to make some of
these observations ...

Some comments inline:

The think you should think about is that .Net did not come about just
because Microsoft decided they needed to invent something new. It came about because of Necessity.

Sure, but what has that to do with Access or ADPs? Oh, wait, you mean
Microsoft suddenly understood Access was crap, and decided to invent
..Net to replace it? Come on...

Yes, there are always workarounds that can be done in Access that .Net does as far as data processing. But, for example, I reduced a giant ADP application with hundreds of tables, procedures, UDFs and tens of thousands of lines of code to just a few dozen tables, procedures, udfs and only a few thousand lines of code. It took me about a year. The benefit of this upgrade was that everytime the business needed to add something or make a change, I didn't have to wade through tens of thousands of lines of code, and didn't have to deal with all the dependencies of hundreds of tables, procedures... I was able to encapsulate the majority of the processing within the .Net application.

This has nothing to do with ADP vs .Net, it's about bad design, and
redesigning. For a good developer, it doesn't matter which tool or
technology is used for the reimplementation, they would simply use
the tool of choice for the organization.

You seem to fancy stuffing all the business logic into the
application. Doing that vs putting it into the database is also an
ongoing discussion, and not everyone would agree that your chosen
design represents good design.

This touches on one of the advantages of ADPs over mdbs, that you can
put more of the business logic on the server.

As for my example, it is just an example. The workaround in Access
would be to add a column to the table for each user. But what if you
have 2000 users? That would exceed the column limits of any sql table. My example is normalized. Of course, if you have 2000 users you could add a dozen tables. But that is way redundant. In .Net I would just read the query results into a dataset and display the results in a datagridview. No tables on the disk.

If you really believe that to present something in an ADP, where you
can just stuff a query result into a dataset using some .Net
technology, would mean a completely ridiculous denormalization, then
to be *very* diplomatic - I think you are mistaken!

And if I may ask, what on earth made you come to that conclusion?
What's so different between an ADO.Net Dataset and an ADO Recordset
in this context?

And also - what do you mean by "No tables on the disk"? Where does
that come into the equotation? Sure, to have a recordset persistant
between sessions, you could save it to disk, but I don't see the
relevance with regards to your Dataset/denormalization issue.

I am sure that when Access first came out the Dbase people were
stressing because they were going to have learn VBA to use Access. But the benefit was that Access could produce applications that would take 10 times as long in Dbase and ran way more efficiently. Well, now there is 10 times as much data to deal with, and Access is where Dbase was 15 years ago. I am sure people are stressing because they are now going to have to learn .Net to deal effectively with this increased volume of data and having to deal with data on the web.

I fail to see how the amount of data relates to the discussion of
ADP vs .Net, as you don't store the data in the client, neither
should you process all of your data client side. Isn't that what
client server is all about? Processing on the server, showing only
the results on the client?

If amount of data matters for you, then most likely you are doing
something wrong. I don't think it's fair to bash the technology
because of that (though, it is quite common).

Data on the web is a fair point.

But the benefit is that Net can produce applications that can handle today's volume of data way more quickly than Access.

Eh...

Does an SQL server SP run faster when triggered from a .Net
application vs being triggered from an ADP app?

Do you fill a datagridview, listview or whatnot any faster in any
..Net tools than you do a bound or unbound ADP control?

Is it really true that a n-tier/OO .Net application "handle today's
volume of data way more quicly than Access."? I mean, shuffling
all of those objects back and forth through the layers'n'stuff ...

And why should a client application "handle today's volume of data"
anyway? Shouldn't the server handle this, and only present the
results to the client?

But the difference between the Dbase/Access paradigm and the Access/.Net paradigm is that Access was a complete departure from Dbase. Where .Net is basically an extension of Access (on the VB side that is). Same object models Just taken to the next level (the extreme next level).

I still use Access for personal projects like my checkbook, pilot log
book, contacts book. So Access will continue to exist (unlike Dbase)
for personal use and for training - great training tool. I just
wouldn't use it for enterprise development.

But who use Access for Enterprise Level Development?

As for my experience, I have been doing enterprise level developing for about 10 years now, and smaller scale developing since the mid 80s. I started the RDBMS corporate scene with Access2 and VB4 and sql server 6.5. By Access2000 I was stepping up to .Net. At first I could not see the benefit. But by VS2005, the benefit was quite obvious. VS2005 (.Net 2.0) is to VS2002(.Net 1.0) what Access 20003 was to Access2000 - a significant improvement - a vast improvement in .Net. Believe me, once you give VS2005 a try you will see what I mean.

Rich

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

--
Roy-Vidar


.

Relevant Pages

  • ADP payroll in-security
    ... I'm looking for people with experience using a particular ADP ... ADP does not normally provide a remote server IP address. ... internal or on the Internet. ... the client PC or remote host connecting to it. ...
    (comp.security.misc)
  • ADP payroll in-security
    ... I'm looking for people with experience using a particular ADP ... ADP does not normally provide a remote server IP address. ... internal or on the Internet. ... the client PC or remote host connecting to it. ...
    (comp.security.firewalls)
  • Re: Troubleshoot connecting client to SQL Server instance on a server
    ... ADP doesn't use TCP but named pipes ... machine or if SERVER is an alias that you have created. ... When I open the ADP file on the client, ... configured SQL Server Express on the server to accept client ...
    (microsoft.public.access.adp.sqlserver)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
Loading