Questions on switching from local to production replicas
Hervé Savary
I have never used Jet Replication (nor another one) and after reading
a bunch of posts and docs (mainly from top expert David W. Fenton) I
did not find the scenario I was thinking to work with, so here it is:
I have my app splited in FE/BE and running under Access 2002 runtime
on a wired LAN, with desktops and laptops connected to a NAS server.
On the NAS I would have:
Design Master (priority 100 - not involved in any sync except for
keeping it from expiring)
Production Replica (priority 90)
Hub Replica (priority 81 used as a Farm/Buffer among the others)
And on each laptop: a Local Replica (priority 90 – to Direct Sync with
Prod through Hub)
Now, I understand that replication is not suitable for “real time
system” needs. But my users have their calendars frequently updated,
and as their needs for working outside of the main office is only 1
day a week (sometimes even 1 day a month) I was thinking to avoid the
synchronisation latency, during their stay in main office, by linking
all laptop’s FE with the Prod Replica on the NAS, and switch to the
laptop BE only when they need to go outside.
Obviously, every Local Replica would be sync daily with the Hub
Replica at start and shut down of app (although if I will use only
Direct Sync, I think I will use the TSI Synchronizer which I already
tested and found working great).
Did I missed something that makes that switching between more FE/BE
not a valid scenario or too risky with replication?
The mainly pitfall I can see is on preventing a user, when linked to
the Prod Replica on server, to synchronize with the Hub, while another
user is editing the BE, right? Is there a mean to check for that
situation before to sync or scheduling the sync between Prod and Hub
is the only way?
Beyond the point above on security, Is there any other aspect I should
consider in using the same synchroniser (the one on each laptop) to
perform synchronisation upon all three Production, Hub and Local
replicas, like in handling conflicts for example?
Are they correctly managed with the loosing priority given to the Hub
(as I read David recommend)?
I read also David’s suggestion for having a backup replica on laptop,
to sync with prod replica on shut down. What would be the interests
for having that specific one compare to the possibility to replace the
local replica with a copy of the prod replica updated?
Thank you for any advice.
Hervé Savary
hrv...@gmail.com
David W. Fenton
news:4274547a-6c13-4041...@t7g2000vbj.googlegroups.com
:
> Hi all replicants,
> I have never used Jet Replication (nor another one) and after
> reading a bunch of posts and docs (mainly from top expert David W.
> Fenton) I did not find the scenario I was thinking to work with,
> so here it is:
>
> I have my app splited in FE/BE and running under Access 2002
> runtime on a wired LAN, with desktops and laptops connected to a
> NAS server.
It the NAS server is using NTFS as its file system, I'd say OK, but
if it's not a native Windows file system, I'd be wary -- I know
people have had wild success with Linux servers and Samba, but I'm
very nervous about a non-Windows file system with Jet.
> On the NAS I would have:
> Design Master (priority 100 - not involved in any sync except for
> keeping it from expiring)
> Production Replica (priority 90)
> Hub Replica (priority 81 used as a Farm/Buffer among the others)
I have some problems with this. Because you're using a NAS as your
file server, the replicas are always being pulled across the wire,
and are never local to the RAM of the machine you're running the
synch on (whether direct or indirect).
> And on each laptop: a Local Replica (priority 90 – to Direct Sync
> with Prod through Hub)
> Now, I understand that replication is not suitable for “real time
> system” needs. But my users have their calendars frequently
> updated, and as their needs for working outside of the main office
> is only 1 day a week (sometimes even 1 day a month) I was thinking
> to avoid the synchronisation latency, during their stay in main
> office, by linking all laptop’s FE with the Prod Replica on the
> NAS, and switch to the laptop BE only when they need to go
> outside.
You could have the startup of your app check if the production
replica is available, which means they are connected to the LAN, and
changed the linked tables to point to that if they are, and point
them to the replica on the laptop when they're not.
You'd also want to synch between the local replica and the
production replica on every shutdown of the application when the
linked tables are pointing to the production replica.
The only monkeywrench is if they use a VPN connection when in the
field, because that will look like they are connected to the wired
LAN, but it's not suitable for editing. The solution to that will
depend on your VPN's configuration. One way to detect it is if the
VPN has a reserved block of IP addresses, but that can be a little
tricky to detect because you'll have multiple IP addresses (one for
the Internet connection, another for the VPN).
> Obviously, every Local Replica would be sync daily with the Hub
> Replica at start and shut down of app (although if I will use only
> Direct Sync, I think I will use the TSI Synchronizer which I
> already tested and found working great).
When you're connected to the LAN, there's really no reason to bother
with all the trouble -- a direct synch is just fine.
> Did I missed something that makes that switching between more
> FE/BE not a valid scenario or too risky with replication?
It can be a little tricky. You need a good reliable network
detection, and I'd suggest using the File System Object FileExists
function. It can easily be used with late binding, and there was a
recent discussion of using it in one of the Access newsgroups (I
participated, posting my code for the function I use to detect the
availability of the network, which uses FolderExists instead of
FileExists).
> The mainly pitfall I can see is on preventing a user, when linked
> to the Prod Replica on server, to synchronize with the Hub, while
> another user is editing the BE, right?
I'm not sure I'm getting the problem. If you're running scheduled
synchs between the hub and production replicas, the problem is no
different than if a user initiates a synch between the local replica
and the production replica.
> Is there a mean to check for that
> situation before to sync or scheduling the sync between Prod and
> Hub is the only way?
If you're using the hub for indirect synchs, one way is to put it in
a non-shared location, i.e., not accessible from the network. But
that doesn't work with your NAS -- it only works on a file server
running the synchronizer in its RAM.
> Beyond the point above on security, Is there any other aspect I
> should consider in using the same synchroniser (the one on each
> laptop) to perform synchronisation upon all three Production, Hub
> and Local replicas, like in handling conflicts for example?
I don't understand the question. There's only ever one synchronizer
per PC, and only ever two possible synchronizers to synch any two
replicas indirectly.
This is one of the flaws of using a NAS. You still have to have a
single machine that is running the synchronizer that will be
managing the hub. You can't have the hub managed by more than one
synchronizer. Indeed, I'd suggest it's bad to have any replicas
managed by more than one synchronizer.
> Are they correctly managed with the loosing priority given to the
> Hub (as I read David recommend)?
Since the hub has no edits, conflicts can never develop. If they do
somehow, the hub will lose because of its lower priority.
> I read also David’s suggestion for having a backup replica on
> laptop, to sync with prod replica on shut down. What would be the
> interests for having that specific one compare to the possibility
> to replace the local replica with a copy of the prod replica
> updated?
It's one more redundant backup. Every time something goes wrong with
your regular backups, you need those extra backups. Think of it as
the smallest possible replica farm on each laptop.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
Hervé Savary
wrote:
> Hervé Savary <hrv...@gmail.com> wrote innews:4274547a-6c13-4041...@t7g2000vbj.googlegroups.com
Many thanks David for your responses and thanks too for your function
I found to detect the availability of the network. Being just a
“technical user”, not a “native programmer”, I would have some more
questions, If you don’t mind…
First of all, yes the NAS file system is NTFS and users will not use
(for now) a VPN connection when in the field.
>You'd also want to synch between the local replica and the
>production replica on every shutdown of the application when the
>linked tables are pointing to the production replica.
Yes, but all users being linked to production replica when in office,
what if someone is editing at that moment? That why I was just
thinking to schedule at night, but if I have understood you, I can’t
because the NAS is not able to run the synchronizer in its RAM. Right?
So, for having a complete synchronization with any laptop coming back
to mother ship (or before they go in the field) I should have done:
a) Direct sync with Prod and Hub
b) Direct sync with Laptop and Hub
c) Direct sync with Prod and Hub
Right?
>There's only ever one synchronizer
>per PC, and only ever two possible synchronizers to synch any two
>replicas indirectly.
>This is one of the flaws of using a NAS. You still have to have a
>single machine that is running the synchronizer that will be
>managing the hub. You can't have the hub managed by more than one
>synchronizer. Indeed, I'd suggest it's bad to have any replicas
>managed by more than one synchronizer.
Excuse me but I’m not sure to understand. Do you mean that having each
laptop synchronizer (once at a time) managing either the Hub and
Production replicas, is not a good practice? If so, is it at least
workable unless a better solution?
In addition to the configuration considerations above, I’m a bit
nervous by replication troubles like dead replicas or losses of
replicability and have some questions about.
After reading your posts I know that I have to unbound my Memo fields.
Assuming bound Memos don’t exist anymore, Is the risk remain
prohibitive in synchronising while someone is editing?
I know also that I should never copy (duplicate) the replication
fields from a record to another. If I need to duplicate a record, what
would be the best way to exclude these system fields with DAO?
At last, I read that you don’t recommend to compact the BE. Is it
because it introduce the possibility to end up with dead replicas
(db1, db2 and so on, created when Access fails to rename the data file
after compacting, and that someone could wrongly open)? Assuming the
replica is always replaced in the same location after compacting, is
it safe to compact or you would not recommend it in any case?
Is there any else pitfall I should be aware (apart the fact that, as
far I can see, I'm about to get myself into an adventure almost as
dangerous as a marriage!)?
Thanks again for your time and your help in sharing your knowledge.
Hervé Savary
David W. Fenton
m:
> First of all, yes the NAS file system is NTFS and users will not
> use (for now) a VPN connection when in the field.
You're certain the NAS device is running Windows? I've dealt with a
lot of them, and all the ones I've used have been Linux-based.
>>You'd also want to synch between the local replica and the
>>production replica on every shutdown of the application when the
>>linked tables are pointing to the production replica.
>
> Yes, but all users being linked to production replica when in
> office, what if someone is editing at that moment?
What if they are? The only danger is if you're editing memo fields
with bound controls. If you're not doing that, there's no danger,
but the drawback is that some updates may not be able to be
propagated. But in that event, they'll be resent on the next synch.
Those will only be updates, as no other kind of operation is blocked
(adds and deletes are not blockable by a user editing a record
unless the edited record is the record being deleted or is somehow
related to a record to be deleted).
It's customary to set up a production replica and hub replica on a
synch schedule that runs during the day, for example, every hour, in
order that remote users synchronizing with the replication hub will
have data that's as up-to-date as possible. Since a remote
synchronizer can't initiate a synch between the hub and the
production replica, it has to happen automatically, so you're really
faced with the same problem.
If you're not supporting any remote synchs, then I can't say that a
hub replica is really required in the first place.
> That why I was just
> thinking to schedule at night, but if I have understood you, I
> can't because the NAS is not able to run the synchronizer in its
> RAM.
Well, you can schedule it overnight if you have a computer running
the synchronizer that is on overnight. If there is a dedicated
Windows file server, that would be the appropriate place for the
synchronizer to be running. But if you have that, that's also the
appropriate place for storing the production replica and the
replication hub.
> Right?
> So, for having a complete synchronization with any laptop coming
> back to mother ship (or before they go in the field) I should have
> done: a) Direct sync with Prod and Hub
> b) Direct sync with Laptop and Hub
> c) Direct sync with Prod and Hub
> Right?
If there are any conflicts produced, you'll discover them after the
last of those 3 synchs, and they should be resolved at that point,
in which case you'd need to redo the first two steps to propagate
the resolved conflicts.
I don't see what the point is of not just synching directly with the
production replica. You have to have some form of scheduled synch to
keep the hub up-to-date if you're supporting remote synchronization,
so you've already got synchs happening while users are editing the
production replica. Adding the occasional synch by the laptop users
doesn't seem like that big of a deal to me, since you would be
dealing with the problems already.
>>There's only ever one synchronizer
>>per PC, and only ever two possible synchronizers to synch any two
>>replicas indirectly.
>>This is one of the flaws of using a NAS. You still have to have a
>>single machine that is running the synchronizer that will be
>>managing the hub. You can't have the hub managed by more than one
>>synchronizer. Indeed, I'd suggest it's bad to have any replicas
>>managed by more than one synchronizer.
>
> Excuse me but I'm not sure to understand. Do you mean that having
> each laptop synchronizer (once at a time) managing either the Hub
> and Production replicas, is not a good practice? If so, is it at
> least workable unless a better solution?
Right. Each replica should be managed by only one synchronizer. I've
never heard of doing anything else, and I don't know what the issues
are. It sounds like a recipe for disaster to me.
The problem in your scenario is that you're storing your hub on a
device that can't run the synchronizer. I take as one of my main
principles that a synchronizer should only ever manage replicas
stored on the same machine as the synchronizer is running on.
A NAS device throws a monkey-wrench in that scenario. If had an
environment where there was no file server to run the synchronizer
and host the hub replica, I think I'd designate one machine as de
facto file server, and let it run the single synchronizer that
manages the hub replica. Whether or not I'd store the hub replica on
the NAS or not is a sticky question. I'd argue against it, putting
the hub replica on the same machine that's running the synchronizer.
This is all inline with Best Practices as outlined on the Jet
Replication Wiki:
http://dfenton.com/DFA/Replication/index.php?title=Best_Practices
Note that this article is the one thing on the site that I didn't
write!
> In addition to the configuration considerations above, I'm a bit
> nervous by replication troubles like dead replicas or losses of
> replicability and have some questions about.
> After reading your posts I know that I have to unbound my Memo
> fields. Assuming bound Memos don't exist anymore, Is the risk
> remain prohibitive in synchronising while someone is editing?
I don't believe there's any longer any data loss issue.
But there is the issue of retries for synchs that fail because a
record is locked. Whether or not that's a significant issue depends
on your particular database schema and the business rules. In
general, I'd say that any schema for which that's a problem is
probably one that's not well-suited to replication in the first
place, so basically (assuming replication is suitable in the first
place), it's probably not going to be a major issue. If synchs are
scheduled reasonably often, the latency for blocked synchs is going
to be only as long as the synch period.
> I know also that I should never copy (duplicate) the replication
> fields from a record to another. If I need to duplicate a record,
> what would be the best way to exclude these system fields with
> DAO?
Not sure I understand your question, but if you need to duplicate a
record in a replicated table, you'd append a copy of the record
excluding the replication fields and the PK.
> At last, I read that you don't recommend to compact the BE.
Where did you read that? I didn't say that. You compact the BE just
as often as you would in a non-replicated app. And when you're doing
schema changes, you do so more often, since properly propagating a
schema changes actually requires two compacts to clean up
everything.
> Is it
> because it introduce the possibility to end up with dead replicas
> (db1, db2 and so on, created when Access fails to rename the data
> file after compacting, and that someone could wrongly open)?
The files from a failed compact are never going to be used, so I
don't see there's any danger from them.
> Assuming the
> replica is always replaced in the same location after compacting,
> is it safe to compact or you would not recommend it in any case?
A compact consists of two steps:
1. write a new database that is compacted.
2. delete the original and rename the new one to the original name.
The new database will have the same ReplicaID and the same name and
be in the same location, so, even though it's technically a
completely different file, it functions just fine as the original
replica.
So, I don't really see any issues with compacting at all.
> Is there any else pitfall I should be aware (apart the fact that,
> as far I can see, I'm about to get myself into an adventure almost
> as dangerous as a marriage!)?
Everything I know is in the Wiki and my posts in this newsgroup.
You'll learn a lot more by reading Michael Kaplan's postings in this
newsgroup and his articles at http://trigeminal.com. Other than
that, I don't know what to say.
Hervé Savary
wrote:
> Hervé Savary <hrv...@gmail.com> wrote innews:bbe592aa-0991-44fd...@q26g2000vbn.googlegroups.co
> that, I don't know what to say.
>
> --
> David W. Fenton http://www.dfenton.com/
> contact via website only http://www.dfenton.com/DFA/
Thanks David, your answers clarifies my confusions.
>You're certain the NAS device is running Windows? I've dealt with a
>lot of them, and all the ones I've used have been Linux-based.
This NAS (Synology DS 209) can run as a Windows File Server CIFS. Id
did some test and seems OK.
Regarding Hub replica, yes I don’t have to support any remote synchs
and thus I don’t really need it, and this simplifies things.
Some extra questions:
When I create a set of replica with the the MakeReplica method of the
TSI (that creates an additional replica) I have either the DM and the
other replica created with priority 90. Why DM don’t have a 100
priority?
In order to provide the users with a UI to resolve conflicts, I was
thinking to check for records in MSysConflicts and if so, to open
WzCnflct.exe using shell. I tried and seems to work. What do you
think?
As an alternative to the backup local replica, is a copy of this one
(saved in a non shared folder) could be used to replace the same
replica at the same location, if corrupted?
>> At last, I read that you don't recommend to compact the BE.
>Where did you read that? I didn't say that.
I was referring to some of your posts I read like that one (Access
Monster Forum 06 Jun 2008):
>“Well, for one, you should never under any circumstances enable
>"COMPACT ON CLOSE" as it's a useless and dangerous "feature" of
>Access that never should have been implemented….”
Now I got the nuance: ON CLOSE. So, the FE mde files don’t need it and
for the BE mdb files enough to have the command in menu for a
restricted use.
I was also thinking to check on shut down (let’s say every 30 days) if
there is no other user connected to BE then compact. Good or bad idea?
Many thanks again,
Hervé
David W. Fenton
:
>>You're certain the NAS device is running Windows? I've dealt with
>>a lot of them, and all the ones I've used have been Linux-based.
>
> This NAS (Synology DS 209) can run as a Windows File Server CIFS.
> Id did some test and seems OK.
I don't think the NAS is running NTFS at all. I checked the specs
here:
http://www.synology.com/enu/products/DS209/spec.php
It say this:
File System
* EXT4
* EXT3
* FAT32 (External Disk Only)
* NTFS (External Disk Only)
That means it supports NTFS only on an external disk attached to the
NAS. The fact that the file systems supported on the NAS itself is
EXT3/4 means it's likely running Linux.
The CIFS support is likely provided by Samba. It has nothing to do
with the underlying OS -- it's only a networking protocoll
> Regarding Hub replica, yes I don't have to support any remote
> synchs and thus I don't really need it, and this simplifies
> things.
>
> Some extra questions:
> When I create a set of replica with the the MakeReplica method of
> the TSI (that creates an additional replica) I have either the DM
> and the other replica created with priority 90. Why DM don't have
> a 100 priority?
That indicates that the DM has been recovered from a replica that
had lower priority. I don't know if it's possible to create a
replica with higher priority from a replica with lower priority.
I don't think it actually matters, to be honest, as the DM has no
edits, and replica priority is really only relevant to default
conflict resolution.
> In order to provide the users with a UI to resolve conflicts, I
> was thinking to check for records in MSysConflicts and if so, to
> open WzCnflct.exe using shell. I tried and seems to work. What do
> you think?
That's exactly what I do.
> As an alternative to the backup local replica, is a copy of this
> one (saved in a non shared folder) could be used to replace the
> same replica at the same location, if corrupted?
I'd likely create a new replica from the backup (just by copying it,
in fact), but you might want to control replica priority, and if
your backup replica were not the appropriate priority you wouldn't
want to do that.
The point of the backup replica is the same as with any replica farm
-- to have more redundant copies of your data in case a replica is
lost.
>>> At last, I read that you don't recommend to compact the BE.
>>Where did you read that? I didn't say that.
>
> I was referring to some of your posts I read like that one (Access
> Monster Forum 06 Jun 2008):
>
>>"Well, for one, you should never under any circumstances enable
>>"COMPACT ON CLOSE" as it's a useless and dangerous "feature" of
>>Access that never should have been implemented.."
>
> Now I got the nuance: ON CLOSE.
COMPACT ON CLOSE has nothing to do with replication. It's equally
dangerous and useless for all files, whether replicated or not.
> So, the FE mde files don't need it and
> for the BE mdb files enough to have the command in menu for a
> restricted use.
> I was also thinking to check on shut down (let's say every 30
> days) if there is no other user connected to BE then compact. Good
> or bad idea?
I schedule compacts on my file server overnight or once a week using
a VBScript. Whether or not I care if it fails because someone has it
open varies from case to case. If it matters, I put code in the
front end to log people out at midnight (or some other appropriate
time), but I currently don't have any applications where that is
required.
I would like to return to an issue you have not responded to, and
that's the whole issue of using a NAS and how synchronizers work. I
believe that because of the nature of what a synchronizer does, it's
imperative that the synchronizer be running in the RAM of the same
machine that the hard drive is installed in. That means no managing
of replicas across a network connection (which disqualifies NAS
devices for use in this scenario). The reason is that you want the
safest possible synchronization processes, and the communication
between the synchronizer and the replica it's managing needs to be
as reliable as possible.
But I don't even know why you need a synchronizer at all, or any
managed replicase, since you're not using indirect replication. The
only reason I can think of is in order to maintain a replica farm
for backups. I'm not sure if I'd do that or just schedule synchs in
the file server's task scheduler using VBScripts and DAO.
Also, if you're not using indirect replication to synch remotely, I
don't know why you're managing replicas on the laptops.
Additionally, I believe any single replica should be managed by only
one synchronizer. I mentioned that before and I don't know if you've
corrected that or not.
In short, it seems to me as though you've really over-engineered
your replication topology. In the kind of environment you're working
in, I wouldn't use the TSI Synchronizer or the Jet synchronizer at
all -- I'd just use plain old DAO to do all my synchronizing, and if
I wanted a replica farm as backup on my file server, I'd just use
VBScript with DAO and schedule that to run at appropriate intervals.
Hervé Savary
wrote:
> Hervé Savary <hrv...@gmail.com> wrote innews:269d2833-3a50-4718...@q9g2000vbd.googlegroups.com
Hi David,
Thank you for having checked the spec of the NAS.
Well, in first place my idea was to use this NAS as mother ship since
it was the only storage device available permanently in the office, on
witch the secretary could updated patient files and appointments for
therapists (laptop users going in the field). But as you said:
> it's imperative that the synchronizer be running in the RAM of the same
>machine that the hard drive is installed in. That means no managing
>of replicas across a network connection (which disqualifies NAS
>devices for use in this scenario).
So even in the case I don’t use any synchronizer to direct sync
between laptops/desktop, the NAS is still disqualified because of the
non NTFS supported. Right?
>In short, it seems to me as though you've really over-engineered
>your replication topology.
So even with no server files in my topology at the moment, can I just
have DM and Production replicas (office replica) on a Desktop?
>In the kind of environment you're working in,
>I wouldn't use the TSI Synchronizer or the Jet synchronizer at all
>I'd just use plain old DAO to do all my synchronizing
So I should be able to handle the whole thing with just DAO and
WzCnflct.exe, without anything else?
I was thinking to use TSI Synchronizer in first place because of some
of its features (like the Move command, the progress bar for
synching…). If I don’t, what are the alternatives to those features
with DAO?
>and if I wanted a replica farm as backup on my file server, I'd just use
>VBScript with DAO and schedule that to run at appropriate intervals.
Can I find somewhere some code examples of that?
Many thanks for pointing me in the right direction, without your
advices, I went straight into the wall!
Hervé Savary
David W. Fenton
news:9e56fc90-15dc-4846...@k13g2000vbq.googlegroups.co
m:
> Thank you for having checked the spec of the NAS.
> Well, in first place my idea was to use this NAS as mother ship
> since it was the only storage device available permanently in the
> office, on witch the secretary could updated patient files and
> appointments for therapists (laptop users going in the field). But
> as you said:
Given that it's not clear to me that you need the synchronizer at
all, seems to me that you're OK with the NAS -- it's just a file
server.
That said, I don't let my clients edit any Jet/ACE files stored on a
non-native Windows file system.
>> it's imperative that the synchronizer be running in the RAM of
>> the same
>>machine that the hard drive is installed in. That means no
>>managing of replicas across a network connection (which
>>disqualifies NAS devices for use in this scenario).
>
> So even in the case I don't use any synchronizer to direct sync
> between laptops/desktop, the NAS is still disqualified because of
> the non NTFS supported. Right?
If you're not using the synchronizer, it's a moot point entirely.
>>In short, it seems to me as though you've really over-engineered
>>your replication topology.
>
> So even with no server files in my topology at the moment, can I
> just have DM and Production replicas (office replica) on a
> Desktop?
Sure. Windows Workstation is binary identical to Windows Server, and
just has certain registry keys and security set differently. Though
the exact components installed with each differ, the subsystems that
control networking and file sharing are identical.
The issues with using a workstation as peer-to-peer file server are:
1. Security: if you use the EVERYONE group, you avoid the problem,
but that means it's also available to anyone connected to your local
LAN.
2. Reliability/Performance: if it's a workstation and the user
sitting at it is editing big graphics files, it can interfere with
the machine's server functioning. Also, if the user turns off the
machine, the file is no longer available, or if the machine crashes,
etc.
If you've got more than two or three workstations, I'd say you need
a dedicated server. It can be an old PC running a non-server version
of Windows, if necessary -- that's better than multi-purposing a
workstation that's in use all the time.
>>In the kind of environment you're working in,
>>I wouldn't use the TSI Synchronizer or the Jet synchronizer at all
>>I'd just use plain old DAO to do all my synchronizing
>
> So I should be able to handle the whole thing with just DAO and
> WzCnflct.exe, without anything else?
I would say so. Unless you've left out important parts of the
equation, I don't see any reason why you need to run the
synchronizer at all.
> I was thinking to use TSI Synchronizer in first place because of
> some of its features (like the Move command, the progress bar for
> synching.). If I don't, what are the alternatives to those
> features with DAO?
Well, you can't get the progress bar, but every user does not need
the MoveReplica command -- that's an administrative function. If
synchs are taking long enough that a progress bar is important, then
there's a problem somewhere. The type of scenario in which direct
synchs are appropriate should be one in which it's the rare synch
operation that should take long enough to benefit from a progress
bar.
FWIW, in all my years of using replication and the TSI Synchronizer,
I've never once used the progress bar from it (didn't even remember
that it existed).
>>and if I wanted a replica farm as backup on my file server, I'd
>>just use VBScript with DAO and schedule that to run at appropriate
>>intervals.
>
> Can I find somewhere some code examples of that?
Basically, it's just like the code for the same thing in Access, but
as if you're using late binding:
Dim objDAO
Set objDBEngine = CreateObject("DAO.DBEngine.36")
Then you'd use that just like you'd use DBEngine in Access. Remember
all variables are variants (so no data typing), and there are no
predefined constants. And you clean up your variables just like you
would in VBA.
Hervé Savary
wrote:
> Herv Savary <hrv...@gmail.com> wrote innews:9e56fc90-15dc-4846...@k13g2000vbq.googlegroups.co
Hi David,
I've been busy these days with some redesigning and optimising of my
app to make it fully compatible with the replication (unbouded all
memo fields, separate MDB for the temp table…) and I am now almost
ready for coding replication and synchronising.
Is the late binding as you suggest (with which I am not familiar) is
necessary even if I use an exe that installs the Access Runtime and
all the necessary references on the target computers?
Concerning the making of the replicas set, I read that “If you use DAO
to convert your database to a Design Master and then create an
additional replica, be sure to open the Design Master first and
synchronize the replicas before you open the second replica”. So, if
you confirm it is correct, the first sync should always be done from
the DM to each replica created, right?
Is there a particular reason you use FolderExists rather than
FileExists in cheking for the network?
Many thanks for your help,
Hervé
David W. Fenton
news:557f6e8a-19e2-4be4...@j18g2000yqd.googlegroups.co
m:
> I've been busy these days with some redesigning and optimising of
> my app to make it fully compatible with the replication (unbouded
> all memo fields, separate MDB for the temp table.) and I am now
> almost ready for coding replication and synchronising.
> Is the late binding as you suggest (with which I am not familiar)
> is necessary even if I use an exe that installs the Access Runtime
> and all the necessary references on the target computers?
The late binding issue (the code I posted) was for use in the
VBScript for scheduling the synch. You don't ever need to use late
binding for DAO in an Access application, as even if you don't have
a DAO reference, you can always get to DAO via the
Application.DBEngine or Application.CurrentDB objects.
> Concerning the making of the replicas set, I read that "If you use
> DAO to convert your database to a Design Master and then create an
> additional replica, be sure to open the Design Master first and
> synchronize the replicas before you open the second replica". So,
> if you confirm it is correct, the first sync should always be done
> from the DM to each replica created, right?
I don't understand the context. If you're converting a
non-replicable database to DM, you do that by creating the first
replica. I'm no sure why those two replicas would not be identical,
except for the fact that one of them is the DM.
> Is there a particular reason you use FolderExists rather than
> FileExists in cheking for the network?
Not particularly. Either is a proxy for something else. I guess I
could weakly defend FolderExists because the folders are less likely
to change than the files, but as I say, that's very weak.
Hervé Savary
wrote:
> Hervé Savary <hrv...@gmail.com> wrote innews:557f6e8a-19e2-4be4...@j18g2000yqd.googlegroups.co
Thank you David you cleared my confusion.
I have implemented the routines to create the replica set and direct
sync with DAO and everything seems to work, and I'm going to test a
number of things…
Now, I must also deal with administrative tasks that will be needed at
one time or another and have some questions about :
The TSI have a “ReplicaSet Property” which is very convenient to
retrieve information about members of the replica set. Is there a way
to get these info from the msysreplica table, through DAO?
When a replica is created by copying the DM, is there a way to edit
the replica’s description with DAO?
In case I need to move a replica what do you suggest: using
replmanager or TSI?
Could I keep the TSI Sync installed just for administration purposes
although I will use only DAO for replication and sync, or it doesn’t
make sense?
Thanks again for your time and your patience with the newbie I am...
Hervé Savary
David W. Fenton
m:
> On 27 sep, 19:40, "David W. Fenton" <NoEm...@SeeSignature.invalid>
> wrote:
>> Hervé Savary <hrv...@gmail.com> wrote
>> innews:557f6e8a-19e2-4be4-9693-23
> 8a083...@j18g2000yqd.googlegroups.co
The information has to come from the replication tables, so you
should be able to query them directly. Note that you can't create
joins on the GUID fields and have to use implicit joins (i.e., WHERE
criteria). You might try both side-by-side, that is use the
ReplicaSet properties and compare the value returned for each to the
data in the replication tables, which should tell you which field is
being returned as which property.
> When a replica is created by copying the DM, is there a way to
> edit the replica’s description with DAO?
Dunno. I don't give a rat's ass about the descriptions. I suspect
they can only be set when the replica is created in code, rather
than by copying.
> In case I need to move a replica what do you suggest: using
> replmanager or TSI?
Whatever you have available. I never acquired the Jet 4 ReplMan, so
must use the TSI Synchronizer. I created a tools database that has
everything I need in it, and basically replaces all the
functionality of ReplMan except the pretty picture and the
scheduling setup dialog.
> Could I keep the TSI Sync installed just for administration
> purposes although I will use only DAO for replication and sync, or
> it doesn’t make sense?
That's precisely what I'd do in your circumstances.
> Thanks again for your time and your patience with the newbie I
> am...
I answer these questions to create a public record to help others.