John W. Colby
jcolby at ColbyConsulting.com
Fri Mar 28 07:26:18 CST 2003
Thanks. 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: Friday, March 28, 2003 2:24 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Replication - A2K ...just a note jc ...www.trigeminal.com is loaded with replication info, code, and tools ...HTH :) 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: "John W. Colby" <jcolby at ColbyConsulting.com> To: <accessd at databaseadvisors.com> Sent: Thursday, March 27, 2003 9:37 PM Subject: RE: [AccessD] Replication - A2K > 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 > ---------------------------------------------------------------------------- ---- > _______________________________________________ > 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: 5400 bytes Desc: not available URL: <http://databaseadvisors.com/pipermail/accessd/attachments/20030328/4580c047/attachment-0001.bin>