John W. Colby
jcolby at ColbyConsulting.com
Thu Mar 27 20:37:54 CST 2003
Precisely (on both counts). There are about 25 users of the database. Virtually ALL of the users are actively editing specific cases. Each case can be handled by anyone, i.e. the first examiner available in the phone queue picks up the phone, opens the record for the person that the phone call is about. In the process of taking the call, info is usually entered into "contact" logs, i.e. info about the phone call. Each claimant's file has an assigned "Examiner" who "runs" the case. That person has to make phone calls to physicians, witnesses, employers etc. Those phone calls also get data logged about them. As you can see from the description, there is not a high degree of concurrency where several people will be in the same case at the same time. My observation of the operation is that there is a very random pattern of data entry since the incoming phone calls are random. There is also a fairly predictive data entry since a case has to be worked, however this side of the operation is not necessarily data entry intensive, nor holding records open for long periods of time. The Examiner calls the physician and requests a doc. Notes that fact in the log, moves on to the next claim. It seems that this type of operation would be perfect for replication, on a 15 minute (or even longer) replication schedule. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of William Hindman Sent: Thursday, March 27, 2003 9:21 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Replication - A2K ...if JC's clients are fairly independent of other's changes to the data, then replication running on a ten minute interval for instance, would definitely provide local speed improvements ...but independence is the real question JC has to answer ...if the insurance company can function using ten minute old data, then the sync updates would consume a practically unnoticed amount of time compared to the effects of localized data access. ...ime most clients desire data concurrency over speed but for those that don't, I believe Arthur Fuller has several long posts in the archives that address successfully setting up and maintaining such functionality. ...of course that would mean jc'd need access to the old archives :))))) William Hindman "You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, The Swiss hold the America's Cup, France is accusing the US of arrogance, and Germany doesn't want to go to war." ----- Original Message ----- From: "Drew Wutka" <DWUTKA at marlow.com> To: <accessd at databaseadvisors.com> Sent: Thursday, March 27, 2003 8:54 PM Subject: RE: [AccessD] Replication - A2K > True, replication wouldn't slow down the normal 'running' processes, but I'm > adding in the sync time to replicate it on every database. > > Drew > > > -----Original Message----- > > From: John W. Colby [mailto:jcolby at colbyconsulting.com] > > Sent: Thursday, March 27, 2003 7:46 PM > > To: accessd at databaseadvisors.com > > Subject: RE: [AccessD] Replication - A2K > > > > Why would the replication slow things down? The FE/BE running locally > > speeds things up by a factor of two. Replication simply allows me to run > > the BE/FE locally on every machine. > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Drew Wutka > > Sent: Thursday, March 27, 2003 8:37 PM > > To: 'accessd at databaseadvisors.com' > > Subject: RE: [AccessD] Replication - A2K > > > > > > Just out of curiousity, what all have you tried to speed things up? It > > sounds like you want to replicate a database to run 'locally' on > > everyone's > > machine. I would be willing to be that would slow things down on it's > > own, > > even if the db is running locally. > > > > Are all of the users on a LAN, or are some accessing this through a VPN? > > In > > that case I could see replication being used. > > > > Drew > > > > -----Original Message----- > > From: John W. Colby [mailto:jcolby at colbyconsulting.com] > > Sent: Thursday, March 27, 2003 7:24 PM > > To: AccessD > > Subject: [AccessD] Replication - A2K > > > > > > I need any info / experiences anyone can share re replication. My > > insurance > > client has a functioning database now that is SLOOOOOooooow. They came > > from > > a "flat file" where they had basically a single table with 125+ fields to > > a > > fully relational FE/BE with of course much expanded functionality - and of > > course the speed isn't anywhere close to the same as the old. No matter > > how > > you explain, the user doesn't know what goes on behind the scenes, and > > doesn't care. All they know is that it is slower. Plus they are adding > > more employees (up to about 25 now from under 20 when I started the > > project - and still climbing). > > > > They will probably go to SQl Server someday but now is not the time > > (money). > > I have been discussing options with them and explained to the tech contact > > the idea behind replication. He has been running a FE / BE development > > copy > > of the db on his desktop and it is about twice as fast. Therefore he > > thinks > > that replication might solve their speed issues for the short term (for a > > year or so) until such time as they could make the move to SQL Server. > > > > So I need info. I have done replication one time, just on my own system, > > just to see how it worked - and that was a long time ago. So I need to > > start a thread with anyone who has current experience on how to set it up, > > what is involved, any good reference material to read, would it work to > > merge the BE/FE back in and also replicate design changes, etc. > > > > Anyone with info out there? > > > > Thanks, > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > > > ---------------------------------------------------- > > Is email taking over your day? Manage your time with eMailBoss. > > Try it free! http://www.eMailBoss.com > > > > > > _______________________________________________ > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > _______________________________________________ > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > > ---------------------------------------------------- > > Is email taking over your day? Manage your time with eMailBoss. > > Try it free! http://www.eMailBoss.com << File: ATT109592.txt >> > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com ---------------------------------------------------- Is email taking over your day? Manage your time with eMailBoss. Try it free! http://www.eMailBoss.com -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4944 bytes Desc: not available URL: <http://databaseadvisors.com/pipermail/accessd/attachments/20030327/36a8c93e/attachment-0001.bin>