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

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.

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