[AccessD] Desperately Seeking!

Hi Marcus:

I will add my comment inline...

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Marcus
Tewksbury
Sent: Saturday, May 03, 2003 7:14 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Desperately Seeking!


First Off, thank you to everyone for contributing your thoughts - it is very
much appreciated.  Let me see if I can account for this and reformulate...

1st.) The notion of deploying multiple copies of the .adp versus one
centralized one to limit the # or recordsets is retarded.  My line of
thinking was one application = one recordset, but that can't be right,
right?  The application would create new recordsets for each user as they
went.

 The number of recordsets created and therefore connections
 has nothing to do how many copies of the application being
 used. It depends how the application is written. Of course
 if you have set up your recordsets to all have persistent
 connections then you will quickly run out of recourses and
 bandwidth.

so, I think my problem/solution deals more with the recordset maintenance
itself.  I'm going to try and break this down into over-writing, and
viewing.

Over-writing:  Yeap - I had been using optimistic locks.  I did a pretty
good job of abstracting the code so it will be easy enough to change the
records to pessimistic.  I'm also going to play around with running "at the
client" and "at the server"

Viewing:  Inside the app I want the users to be able to see deletions,
additions, etc. made by other users.  Which I presume means I am going to
have to Refresh my recordsets.  Is anyone familiar with ODBC refresh rates?
Should I periodically issue Refresh methods on the recordset?  How does a
refresh compare to a requery performance wise?  Because I know requerying
just won't be acceptable because of recordset size.

 I have not used ODBC but performance will depend more on how
 much data has to be acquired from the BE. Keeping the recordsets
 small is one way. The refresh or resync method returns any
 changes in a specific record but the requery method re-executes
 the query that created the original recordset and therefore
 reflects any changes to the dataset. The resync method would
 generate an error if the current record had been deleted by
 another user.

Again, thanks to everyone for your thoughts!

- Marcus







_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com