>On 12/31/05, Gary Monger <[EMAIL PROTECTED]> wrote: >> >> >> It sounds like the problem is best solved by fixing your network issue. I >> doubt the expense of upgrading your network will exceed the expense of a >> homebrewed synchronization solution for VistA. >> >> As the preceding posts indicate, VistA does not lend itself to such >> synchronization. It's a big job, your time has to be worth something. It >> would also require substantial custom code that would be at risk anytime >> you >> load patches. You would then have to ensure that patches did not >> overwrite >> your changes. > > >You make a strong argument. It does seem to be a big job, and I have >decided not to wade into it right now. > >Regarding solving our network, the real solution would be to purchase a >dedicated T line. But that is something like $500-$700 a month, I have been >told. We would like to switch from DSL to Cable, but the cable company >keeps stalling. I think they are trying to strong-arm the hospital (which >we are adjacent to) into purchasing cable service for all the hospital rooms >(which isn't going to happen).
I support the idea that your network connection between sites could almost certainly be greatly improved for much less than a switch to a full T1. As I recall from previous discussion on this topic, your connection seemed to have much lower performance than my home DSL and my 8-10 year old DSL seems to be less than a third of the bottom level speed of newer installations, such as at my sister's house. My ISP offers many grades of service above what I currently have for less than $100 per month so I suspect that yours does too. One possibility would be to get one or more additional low cost lines to use as alternate routes for other network traffic. >>Absent the network issue, it does not appear you have a need for two VistA >>databases. The main advantages I see in multiple databases would be in the robustness of a cross-site backup and the performance and reliability of running each local operation on local resources. Bhaskar's 2nd proposed solution would seem to give you this with no programming. >> ECP is Enterprise Cache Protocol. If you have multiple cache servers, its >> how they talk to each other. You could potentially allow users at both >> sites to connect to a local system that would appear as a single system to >> all. I strongly suspect it requires a good network. The advantage is that >> the remote system is caching the data pages, which should work pretty well >> for typical user operations. However, if you only need to occasionally >> dump all of a patient's data, it may not be the best choice. I suspect that ECP is derived from and may be essentially the same as Datatree's DCP (Distributed Cache Protocol). Given that your network connection between sites seems to be your weak link at this time, this does not seem to me a desireable solution, but if that changes GT.M does have an equivalent protocol for setting up a distributed database. It also supports OMI (the MUMPS standard Open MUMPS Interconnect) for connecting to other MUMPS implementations. I don't know if OMI is supported by Cache' at this time, but at one time, all of the major MUMPS vendors supported OMI to some degree and it works quite well on a fast network. --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
