Jim Lawrence (AccessD)
accessd at shaw.ca
Mon Mar 31 13:06:53 CST 2003
RE: [AccessD] Replication - A2KHi Jim:
Thank you very much for that information. Bare with me for a while and I
will see if I can dig up any information on the tests ran. Unfortunately,
the tests never developed into a full project. I suspect most of the
original detail was lost; I do remember that there was some issues but at
one point the connection stabilized. The test bed was two computers, each
with different BE databases, one Master, one Replicate and it looped out to
our ISP and back again. (It might have been through a VPN connection but as
a company developer I was not involved with the infrastructure.)
Arthur Fuller did a project on replication a few years back and it sounded
quite successful. I am again not sure of any details so Arthur would have to
provide those.
Sorry that I can not be of more help
Jim
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim DeMarco
Sent: Monday, March 31, 2003 9:38 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Replication - A2K
I believe we couldn't get A97 to replicate over the Internet at all so we
tried converting the app to A2K2 and that would only work over VPN. We had
a developer talk to M$ on the phone or via e-mail for a week or two and the
VPN was the only way it would work (M$ could not get replication to work
over the Internet either, FYI). If you had a non-VPN replication working do
you have any "secrets" to share?
Thanks,
Jim DeMarco
-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Monday, March 31, 2003 11:36 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Replication - A2K
Hi Jim:
No, the Access97 replication is done straight through the phone lines.
The government has been using it's own internal network, first through fast
dedicated phone lines and finally an 'Ubiquity' fiber-optic connection that
now covers most of the province. I have ran Access97 through the net and
noticed no major problems but it was only a test and not under full load.
It should be stable in the current versions of Access, even running
across the net. VPN would be good to secure the connections but I am not
sure that it would be any more or less stable than a standard internet
connection.
Jim
---Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim DeMarco
Sent: Monday, March 31, 2003 5:38 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Replication - A2K
Jim are you doing Internet replication then? If so are you using a
VPN? We've encountered some difficulties in running replication over the
Net on A97. Which version are you using?
Thanks,
Jim DeMarco
Director of Product Development
HealthSource/Hudson Health Plan
-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Saturday, March 29, 2003 7:03 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Replication - A2K
Hi John:
I have been running a Access replication application for five years.
There are basically three government offices with about forty total
individuals. The program has both an automatic and manual replication
process programmed in. I have one BE db with one table that is centeral to
the process. This is the file that supplies all the invoice numbers. It is
linked to each site by its URL address. As soon as a ne record is created,
the program goes looking for the next number. If the lines are glogged, that
can take about 30 seconds.
I come in every so often and clean up any duplications because
sometimes the timing is off. The issue only comes up once every couple
months or so. The cost to permentantly resolve the problem, with a nice SQL
BE, is prohibitive so the clients have settled on this type of solution.
There simply is no other inexpensive solution. The cost is either on
a expensive product or an expensive programming process.
HTH
Jim
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Friday, March 28, 2003 8:29 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Replication - A2K
And perhaps the situation is simply different. People don't call
to file claims, they fill out paperwork and submit it. Not that your
situation won't occur, of course it will. I can certainly ask how often it
occurs but having spent 8 months on site I didn't get that it happened
"several times a day". People call to "check" on their claim that is
already in the system - having been entered from a claim form. The folks
handling the phones do take info over the phone, but mostly it is "fill out
this form and mail it in", or "get your doctor to fill out this form and
mail it in" or "get your employer to fill out this form and send it in". No
paperwork, no claim! So people "calling back with info" simply isn't a
common occurrence since they don't ask for verbal information other than
current address and the likes.
I will certainly advise them of the facts behind the
synchronization of course. I get the feeling they will live with the
occasional "out of sync" info in order to get a doubling of effective speed.
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 Wortz, Charles
Sent: Friday, March 28, 2003 11:10 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Replication - A2K
John,
I'm not saying your solution doesn't work. I pointed out a
situation that will arise and that they need to have some procedure in place
to handle it. Whether that procedure is within your solution or something
they will have to handle manually is for them to decide.
As to how often such calls occur, all I can say is when I worked
for my Dad in his insurance agency it happened several times a day that
somebody would call to file a claim but didn't have all the information the
agent needed so they would have to call back later with the additional
information. I doubt that human nature has changed much in the intervening
years.
Charles Wortz
Software Development Division
Texas Education Agency
1701 N. Congress Ave
Austin, TX 78701-1494
512-463-9493
CWortz at tea.state.tx.us
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Friday 2003 Mar 28 09:21
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Replication - A2K
They need an answer, and can't afford SQL Server. This is an
answer. To not look at the realistic options because of the 1 in 1000 (or
whatever) occurrence is not realistic.
I am certainly open to other options. However they just spent 8
months moving an old creaky flat file to a relational MDB FE/BE. They don't
have a budget for a $10,000 solution at the moment. What solution can they
get for $500? Moving to SQl Server will be $5k or more. They don't have
that, they have said so. I have done all of the typical "make sure the
fields are indexed" things.
So rather than saying "this solution doesn't work", why don't
you suggest a solution that does?
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 Wortz,
Charles
Sent: Friday, March 28, 2003 8:33 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Replication - A2K
John,
But what about the situation where a customer calls back five
minutes
later with additional information and gets a different examiner?
How is
the second examiner going to be able to get to the customer's
data if
you replicate on a 15 minute schedule? This may not be a common
occurrence, but it does happen and you need to be able to handle
it.
And don't expect the customer to remember the name of the first
examiner, that solution is a non-starter.
Charles Wortz
----------------------------------------------------------------------
Is email taking over your day? Manage your time with eMailBoss.
Try it free! http://www.eMailBoss.com
****************************************************************************
*******
"This electronic message is intended to be for the use only of the
named recipient, and may contain information from HealthSource/Hudson Health
Plan (HS/HHP) that is confidential or privileged. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution or use of the contents of this message is strictly prohibited.
If you have received this message in error or are not the named recipient,
please notify us immediately, either by contacting the sender at the
electronic mail address noted above or calling HS/HHP at (914) 631-1611. If
you are not the intended recipient, please do not forward this email to
anyone, and delete and destroy all copies of this message. Thank You".
****************************************************************************
*******
****************************************************************************
*******
"This electronic message is intended to be for the use only of the named
recipient, and may contain information from HealthSource/Hudson Health Plan
(HS/HHP) that is confidential or privileged. If you are not the intended
recipient, you are hereby notified that any disclosure, copying,
distribution or use of the contents of this message is strictly prohibited.
If you have received this message in error or are not the named recipient,
please notify us immediately, either by contacting the sender at the
electronic mail address noted above or calling HS/HHP at (914) 631-1611. If
you are not the intended recipient, please do not forward this email to
anyone, and delete and destroy all copies of this message. Thank You".
****************************************************************************
*******
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://databaseadvisors.com/pipermail/accessd/attachments/20030331/5bd8a520/attachment-0001.html>