|
|
I'm having so much trouble - I don't think it should be this hard to
indirect synch with TSI Synchronizer? Maybe I'm completely missing
the boat here...
I've installed both TSI synch 4.0 and the Jet Replication 4.0 files,
and updated the registry. I have machine Boundary18 (laptop running
WindowsXP) and machine Boundarysys (hub machine running Windows Server
2003 64bit). The laptop connects to the server via VPN so I need to
setup indirect synch.
First problem (also in my previous post): I cannot assign an
indirectdropbox through code: (synch.indirectdropbox = "\
\boundary18\blinkdrop") I get a failure error when I run this line.
I can manually set the value in the registry, and I know the
synchronizer IS reading this value b/c .sgn files are being put in
there (although they're empty). So functionally, this is not a big
problem. I am wondering, however, that this an indication of some
incorrect setting somewhere that is also the cause of the my next
problem...
Second problem: Indirect synch does not work. When I run the
following code from my laptop:
Private Sub Command36_Click() 'indirect synch
Dim Synch As Synchronizer
Dim rep As Replica
Dim reps As Replicas
Set Synch = New Synchronizer
Synch.Running = True
Synch.DatabaseName = "C:\testrep\testsynch\tdata.mdb"
Set reps = Synch.ReplicaSet
For Each rep In reps
If rep.MachineName = "boundarysys" Then
Synch.SynchIndirect rep.replicaID
End If
Next rep
Synch.Running = False
Set Synch = Nothing
End Sub
....nothing happens. The code flows right through the
synch.synchindirect line with no errors at all - yet the changed data
does not replicate, no .msg files are created, and the .sgn file that
is created is empty.
I don't even get an error at the synchindirect statement if I have my
VPN disconnected . I would think the computer would error out with
some kind of "cannot find remote synchronizer (or remote dropbox)"
statement when it attempts to synchronize with a synchronizer on a
totally different machine that isn't even connected.
Side questions:
1. I know the synchronizer has to be running full-time on the server
to accept incoming synch requests, but it doesn't have to be running
full-time on the laptops, correct? My understanding is that when one
wants to synchronize, the local synchronizer is loaded on demand with
the synch.running=true statement, then it creates a message file with
all the changes that have been made to the data since the last
synchronization, and then sends this message file to the other
machine's dropbox. From there is it picked up by the other machine's
synchronizer and the changes are made to the data. Do I understand
the process correctly?
2. During testing, I keep verifying what replicas are in my set with
the following code:
Public Function GetInfo() As Integer 'Get Replica Info
Dim tblRep As DAO.Recordset
Dim Synch As Synchronizer
Dim rep As Replica
Dim reps As Replicas
Set tblRep = CurrentDb.OpenRecordset("tblReplicaSet")
Set Synch = New Synchronizer
Synch.Running = True
Synch.DatabaseName = "C:\testrep\testsynch\tdata.mdb"
Set reps = Synch.ReplicaSet
DoCmd.SetWarnings (False)
DoCmd.RunSQL ("Delete * from tblreplicaset")
DoCmd.SetWarnings (True)
For Each rep In reps
tblRep.AddNew
tblRep![Description] = rep.Description
tblRep![Machine Name] = rep.MachineName
tblRep![Synchronizer ID] = rep.SynchronizerID
tblRep![replica id] = rep.ReplicaID
tblRep![replica name] = rep.ReplicaName
tblRep![unc name] = rep.UncName
tblRep.Update
Next rep
Synch.Running = False
Set Synch = Nothing
DoCmd.OpenTable ("tblreplicaset")
End Function
The table that is created in this function shows me all members of the
current replica set that have ever been created. Yet this info has
nothing to do with the ManagedReplicas that I defined through the
Synch.ManagedReplicas.Append statement. Let's say I've made 5
replicas on my laptop, and only appended 2 of them to the
managedreplicas collection. The table still shows all 5 replicas
being cycled through in the For Each....Next statement, even though
the registry shows only 2 replicas in the managedreplicas string. So
what is the purpose of managing replicas if they're all going to be
cycled through anyway when looking for a synchronizer to synch with?
Thanks, David, for your help thus far. Any insights here that you can
share with me?
|
|
leicklda <dkimbrell[ at ]wowway.com> wrote in
news:4ce8cf79-714b-4627-9e02-35032223d901[ at ]i24g2000prf.googlegroups.co
m:
[Quoted Text] > I'm having so much trouble - I don't think it should be this hard
> to indirect synch with TSI Synchronizer? Maybe I'm completely
> missing the boat here...
>
> I've installed both TSI synch 4.0 and the Jet Replication 4.0
> files, and updated the registry. I have machine Boundary18
> (laptop running WindowsXP) and machine Boundarysys (hub machine
> running Windows Server 2003 64bit). The laptop connects to the
> server via VPN so I need to setup indirect synch.
>
> First problem (also in my previous post): I cannot assign an
> indirectdropbox through code: (synch.indirectdropbox = "\
> \boundary18\blinkdrop") I get a failure error when I run this
> line.
Are you running the synchronizer in a logon with full administrative
permissions?
> I can manually set the value in the registry,
Is this done with the same user logon as when you attempt to do it
with the TSI Synchronizer?
> and I know the
> synchronizer IS reading this value b/c .sgn files are being put in
> there (although they're empty). So functionally, this is not a
> big problem. I am wondering, however, that this an indication of
> some incorrect setting somewhere that is also the cause of the my
> next problem...
The only one I can think of is a permissions problem in the
registry.
> Second problem: Indirect synch does not work. When I run the
> following code from my laptop:
>
> Private Sub Command36_Click() 'indirect synch
> Dim Synch As Synchronizer
> Dim rep As Replica
> Dim reps As Replicas
> Set Synch = New Synchronizer
> Synch.Running = True
> Synch.DatabaseName = "C:\testrep\testsynch\tdata.mdb"
> Set reps = Synch.ReplicaSet
> For Each rep In reps
> If rep.MachineName = "boundarysys" Then
> Synch.SynchIndirect rep.replicaID
> End If
> Next rep
> Synch.Running = False
> Set Synch = Nothing
> End Sub
>
> ...nothing happens.
Do you really want to synch with every single replica in the replica
set? Why not start out with code that synchs with a single replica?
That would be something like:
Synch.DatabaseName = "C:\testrep\testsynch\tdata.mdb"
Synch.SynchIndirect "boundarysys"
(I'm assuming "boundarysys" is the name of your synchronizer)
If that works, then you're successful.
> The code flows right through the
> synch.synchindirect line with no errors at all - yet the changed
> data does not replicate, no .msg files are created, and the .sgn
> file that is created is empty.
>
> I don't even get an error at the synchindirect statement if I have
> my VPN disconnected .
That's because indirect synchs are asynchronous -- it will queue it
up so that the next time the synchronizer starts and can see the
remote dropbox, it will put MSG files in the remote dropbox to
notify it that a synch is ready to go.
> I would think the computer would error out with
> some kind of "cannot find remote synchronizer (or remote dropbox)"
> statement when it attempts to synchronize with a synchronizer on a
> totally different machine that isn't even connected.
No, it doesn't. It's because indirect synchs are, by definition,
asynchronous, and don't require that both dropboxes be visible at
once and both synchronizers running in order for the synch to
complete.
> Side questions:
> 1. I know the synchronizer has to be running full-time on the
> server to accept incoming synch requests, but it doesn't have to
> be running full-time on the laptops, correct?
Nope. You can start it up when you need it, and close it when the
synch completes.
> My understanding is that when one
> wants to synchronize, the local synchronizer is loaded on demand
> with the synch.running=true statement, then it creates a message
> file with all the changes that have been made to the data since
> the last synchronization, and then sends this message file to the
> other machine's dropbox.
Yep.
> From there is it picked up by the other machine's
> synchronizer and the changes are made to the data.
Actually, it's a bit more complex than that. The first MSG file is
only a notification saying "Hey, Remote Synchronizer! This is
Synchronzer Local and I manage these replicase (listing Generation
of each) and I'd like to synch with all the replicas managed by
you!" When the remote synchronizer picks up that MSG, it then sends
information back, and when that MSG file is read, only then does any
actual data start being sent.
These initial message files serve the function of determining
exactly which data needs to be exchanged, so as to make the exchange
that follows as efficient as possible.
> Do I understand
> the process correctly?
With the exception of telescoping the process into too few steps, it
would seem so.
> 2. During testing, I keep verifying what replicas are in my set
> with the following code:
>
> Public Function GetInfo() As Integer 'Get Replica Info
> Dim tblRep As DAO.Recordset
> Dim Synch As Synchronizer
> Dim rep As Replica
> Dim reps As Replicas
> Set tblRep = CurrentDb.OpenRecordset("tblReplicaSet")
> Set Synch = New Synchronizer
> Synch.Running = True
> Synch.DatabaseName = "C:\testrep\testsynch\tdata.mdb"
> Set reps = Synch.ReplicaSet
> DoCmd.SetWarnings (False)
> DoCmd.RunSQL ("Delete * from tblreplicaset")
> DoCmd.SetWarnings (True)
> For Each rep In reps
> tblRep.AddNew
> tblRep![Description] = rep.Description
> tblRep![Machine Name] = rep.MachineName
> tblRep![Synchronizer ID] = rep.SynchronizerID
> tblRep![replica id] = rep.ReplicaID
> tblRep![replica name] = rep.ReplicaName
> tblRep![unc name] = rep.UncName
> tblRep.Update
> Next rep
> Synch.Running = False
> Set Synch = Nothing
> DoCmd.OpenTable ("tblreplicaset")
> End Function
>
> The table that is created in this function shows me all members of
> the current replica set that have ever been created. Yet this
> info has nothing to do with the ManagedReplicas that I defined
> through the Synch.ManagedReplicas.Append statement.
Why not change:
Set reps = Synch.ReplicaSet
to:
Set reps = Synch.ManagedReplicas
That will limit your loop to the managed replicas for your local
synchronizer.
> Let's say I've made 5
> replicas on my laptop, and only appended 2 of them to the
> managedreplicas collection. The table still shows all 5
> replicas being cycled through in the For Each....Next statement,
> even though the registry shows only 2 replicas in the
> managedreplicas string. So what is the purpose of managing
> replicas if they're all going to be cycled through anyway when
> looking for a synchronizer to synch with?
You're just looping through the wrong collection.
> Thanks, David, for your help thus far. Any insights here that you
> can share with me?
I would suggest that you take these steps:
1. on the laptop, open the remote dropbox in Windows Explorer.
2. right click and choose NEW and try to create a new TXT file. If
you can do that, your laptop has full write permission on the remote
dropbox. If you can't, then the remote dropbox needs to have its
permissions changed.
3. from the remote server, open the laptop's dropbox in Explorer and
do step #2 there.
An indirect synch can complete only if:
- both synchronizers have been running often enough for all the
message files needed to complete the synch to have been exchanged
(it's easiest if they're both open at once; if they are open
serially, it can take a very long time for a synch to complete).
- both synchronizers need to be able to write to each others'
dropbox (which is what the test above is for).
I usually open both dropboxes when running a synch that I have the
time to observe, since I can then see the MSG files and MDB files
being created, opened (when the LDB appears for the MDB files) and
deleted.
If that all works, then I'm at something of a loss as to why it's
not working. In experience, though, 99% of failed synchs are because
either the dropbox permissions are set wrong or because both
synchronizers are simply not running simultaneously.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|
[Quoted Text] > Are you running the synchronizer in a logon with full administrative
> permissions?
Yes
> Is this done with the same user logon as when you attempt to do it
> with the TSI Synchronizer?
Yes
>
> The only one I can think of is a permissions problem in the
> registry.
>
>
It is not a permissions problem, but the registry scenario IS non-
standard on the server. The laptops have the keys in the standard
place:
HLKM>Software>Microsoft>Jet>4.0
But the server, because it is 64 bit, has the keys in a different
location:
HKLM>Software>Wow6432Node>Microsoft>Jet>4.0
This is where the synchronizer made the registry entries itself...I
had to search the registry to find them. I added the synchronizerpath
string (to PF>CF>MSSh...mstran40.exe) here manually after the other
entries were made automatically. Also, I had to install the
synch40.dll in the SysWOW64 directory because it was the only
directory the system would allow me to register the file in. I don't
think that's a problem though because I was able to reference & use it
with Visual Basic with no problem.
>Why not start out with code that synchs with a single replica?
> That would be something like:
>
> Synch.DatabaseName = "C:\testrep\testsynch\tdata.mdb"
> Synch.SynchIndirect "boundarysys"
I've made this change. Thanks
Does each machine have to have to have a unique synchronizer name?
>
> That's because indirect synchs are asynchronous -- it will queue it
> up so that the next time the synchronizer starts and can see the
> remote dropbox, it will put MSG files in the remote dropbox to
> notify it that a synch is ready to go.
I thought the synch.indirectsynch statement was the official "GO"
command for the local machine's synchronizer to talk to the remote
machine's synchronizer. You're saying it is only the "go" for a
machine talk to it's own synchronizer? So how does one force their
own machine to synch with the server on demand - say if there's a noon
meeting and everyone must have synched by then? Does each user simply
need to make sure their connection to the server is open and the
synchronizers will then communicate automatically? How can one get
confirmation (other than looking at data changes) that this long-
distance data exchange has occurred?
> indirect synchs are, by definition,
> asynchronous, and don't require that both dropboxes be visible at
> once and both synchronizers running in order for the synch to
> complete.
I thought indirect synchs were only unique in that they didn't
exchange data directly through open mdb files (the WAN repercussions
of which I've lived through...) , but rather through msg files in
dropboxes. You're saying also that they don't even need a connection
to the other computer at the time the synchronize command is issued?
The only time we ever synchronize is when we have a meeting and
everyone needs access to everyone else's data right *now*. An open,
live connection to the server will guarantee that data exchange to
happen immediately? This is sort of a repeat of my question above,
but I'll ask again because it seems so important for me to understand.
>
> > Side questions:
> > 1. I know the synchronizer has to be running full-time on the
> > server to accept incoming synch requests, but it doesn't have to
> > be running full-time on the laptops, correct?
>
> Nope. You can start it up when you need it, and close it when the
> synch completes.
OK. Thank you.
> The first MSG file is
> only a notification saying "Hey, Remote Synchronizer! This is
> Synchronzer Local and I manage these replicase (listing Generation
> of each)
"I manage these replicas" - does "these" refer only to the replicas
that are defined in the managedreplicas collection? Or all the
replicas in the current replica set?
>and I'd like to synch with all the replicas managed by
> you!" When the remote synchronizer picks up that MSG, it then sends
> information back, and when that MSG file is read, only then does any
> actual data start being sent.
So what if the remote machine has had no data changes since its last
synchronization, and therefore has no MSG files to send back? Will
the remote machine just do an "import" and the local machine will know
that there are no "exports" to receive?
>
> An indirect synch can complete only if:
>
> - both synchronizers have been running often enough for all the
> message files needed to complete the synch to have been exchanged
Aren't message files created the moment one executes the
"synch.synchindirect" command, and exchanged as soon as a connection
is present to the remote synchronizer? I'm not sure what you mean by
"often enough"
>
> - both synchronizers need to be able to write to each others'
> dropbox (which is what the test above is for).
They definitely can. I did the test you laid out and the permissions
and connections are wide open.
>
> I usually open both dropboxes when running a synch that I have the
> time to observe, since I can then see the MSG files and MDB files
> being created, opened (when the LDB appears for the MDB files) and
> deleted.
OK I'll do this also to monitor anything that (hopefully soon if I
figure this out...) might be going on. I'm sure if I could get this
to work even once and watch msg files being created and exchanged,
I'd understand the process a whole lot better. As of yet though, I've
had no success getting even of .msg file to appear. I'm going to have
a party as soon as I see one appear. And free drinks for you!
|
|
I figured out why I couldn't set the dropbox. I have to set the
databasename property first.
duh
|
|
leicklda <dkimbrell[ at ]wowway.com> wrote in
news:435cba48-4802-4136-bc1e-5e3d4edbdc29[ at ]v22g2000pro.googlegroups.co
m:
[Quoted Text] >> The only one I can think of is a permissions problem in the
>> registry.
>>
>>
> It is not a permissions problem, but the registry scenario IS non-
> standard on the server. The laptops have the keys in the standard
> place:
> HLKM>Software>Microsoft>Jet>4.0
>
> But the server, because it is 64 bit, has the keys in a different
> location:
> HKLM>Software>Wow6432Node>Microsoft>Jet>4.0
OK -- because it's 64-bit, you're going to have to make sure the
synchronizer gets run with the 32-bit subsystem. I'm not sure what
the implications are for that. I do know that many people have
problems running Jet on 64-bit servers.
> This is where the synchronizer made the registry entries
> itself...I had to search the registry to find them. I added the
> synchronizerpath string (to PF>CF>MSSh...mstran40.exe) here
> manually after the other entries were made automatically. Also, I
> had to install the synch40.dll in the SysWOW64 directory because
> it was the only directory the system would allow me to register
> the file in. I don't think that's a problem though because I was
> able to reference & use it with Visual Basic with no problem.
You can start it by doubleclicking it? Can you start it with the TSI
Synchronizers? I expect you may have registration issues with it,
too. Not having any experience with 64-bit Windows, I really have no
advice.
When we work this out, I hope you'll go to my Jet Replication Wiki
and enter some information about your experience with this on 64-bit
Windows.
>>Why not start out with code that synchs with a single replica?
>> That would be something like:
>>
>> Synch.DatabaseName = "C:\testrep\testsynch\tdata.mdb"
>> Synch.SynchIndirect "boundarysys"
>
> I've made this change. Thanks
>
> Does each machine have to have to have a unique synchronizer name?
Yes, of course -- the same way each machine has to have a unique
machine name. It's customary to use the machine name as the
synchronizer name, but not required. I don't know why you'd do
otherwise, since you'd then have to look up the name of the machine
the synchronizer was running on...
>> That's because indirect synchs are asynchronous -- it will queue
>> it up so that the next time the synchronizer starts and can see
>> the remote dropbox, it will put MSG files in the remote dropbox
>> to notify it that a synch is ready to go.
>
> I thought the synch.indirectsynch statement was the official "GO"
> command for the local machine's synchronizer to talk to the remote
> machine's synchronizer.
There is no "talking" between the synchronizers. All that ever
happens is that a synchronizer writes files to a remote dropbox and
reads files from its own dropbox. Initiating a synch tells the
synchronizer "write the appropriate MSG file to the remote dropbox
as soon as that dropbox is available."
> You're saying it is only the "go" for a
> machine talk to it's own synchronizer?
Yes, because the remote machine doesn't do anything until it pings
its own dropbox and sees a message file from another synchronizer
telling it that the remote synchronizer wants to initiate a synch.
> So how does one force their
> own machine to synch with the server on demand - say if there's a
> noon meeting and everyone must have synched by then? Does each
> user simply need to make sure their connection to the server is
> open and the synchronizers will then communicate automatically?
> How can one get confirmation (other than looking at data changes)
> that this long- distance data exchange has occurred?
The TSI Synchronizer help file details how to monitor indirect synch
progress. Well, it tells you how to know when it's finished. You
need to use the SynchIndirect2 method to get back a history object,
though. What you monitor is:
tsiSynch.HistoryItemOfExchangeId([ExchangeID]).SynchStatus)
The ExchangeID is a GUID returned by the SynchIndirect2 method. The
indirect synch is complete when the SynchStatus is greater than 1.
>> indirect synchs are, by definition,
>> asynchronous, and don't require that both dropboxes be visible at
>> once and both synchronizers running in order for the synch to
>> complete.
>
> I thought indirect synchs were only unique in that they didn't
> exchange data directly through open mdb files (the WAN
> repercussions of which I've lived through...) , but rather through
> msg files in dropboxes. You're saying also that they don't even
> need a connection to the other computer at the time the
> synchronize command is issued?
That's correct. You can initiate an indirect synch when it can't
complete it will complete later when the resources become available.
I'd never do that, though, since it is user-unfriendly.
> The only time we ever synchronize is when we have a meeting and
> everyone needs access to everyone else's data right *now*. An
> open, live connection to the server will guarantee that data
> exchange to happen immediately? This is sort of a repeat of my
> question above, but I'll ask again because it seems so important
> for me to understand.
The SynchIndirect2 method gives you what you need to evaluate
whether the indirect synch has completed.
This is another reason why users who are connected to the LAN ought
to use a direct synch, which is, by definition, synchronous (so you
can tell right off the bat that it's completed).
[]
>> The first MSG file is
>> only a notification saying "Hey, Remote Synchronizer! This is
>> Synchronzer Local and I manage these replicase (listing
>> Generation of each)
>
> "I manage these replicas" - does "these" refer only to the
> replicas that are defined in the managedreplicas collection? Or
> all the replicas in the current replica set?
Only the managed replicas. A synchronizer cannot do anything at all
to synchronize a replica it's not managing.
>>and I'd like to synch with all the replicas managed by
>> you!" When the remote synchronizer picks up that MSG, it then
>> sends information back, and when that MSG file is read, only then
>> does any actual data start being sent.
>
> So what if the remote machine has had no data changes since its
> last synchronization, and therefore has no MSG files to send back?
There will always be MSG files, even if all the return MSG file says
is "Nothing to send you!"
> Will
> the remote machine just do an "import" and the local machine will
> know that there are no "exports" to receive?
The initial MSG files are for metadata, and are used to determine
what, if anything, needs to be sent to the remote synchronizer to
synchronize the replicas involved. If the replicas are already
identical, these MSG files will simply allow the synchronizers to
determine that nothing actually needs to be sent at all.
>> An indirect synch can complete only if:
>>
>> - both synchronizers have been running often enough for all the
>> message files needed to complete the synch to have been exchanged
>
> Aren't message files created the moment one executes the
> "synch.synchindirect" command, and exchanged as soon as a
> connection is present to the remote synchronizer? I'm not sure
> what you mean by "often enough"
Well, consider this scenario:
1. local synchronizer is running and places a MSG file in the remote
dropbox to initiate a synch.
2. synch remains panding, because remote synchronizer is not
running.
3. remote synchronizer starts up, but the local machine is off the
network. The remote synchronizer can't do anything at all, since the
local dropbox is not available.
4. local machine connects to network, remote synchronizer sees local
dropbox and drops a MSG file in the local dropbox to say "Yes, I'm
here and this is what you need to know about my replica in order to
prepare to send data." If the local synchronizer is not running, the
new MSG file will not be processed.
5. local synchronizer starts up and reads the MSG file. But if the
remote dropbox is not accessible, or the remote synchronizer is not
running, the synch can't complete.
Think of it this way: It's the difference between conducting a
conversation on the phone with somebody, and doing the same thing
through leaving messages on each others' voice mail. You may ask the
question: Is it OK if we meet at 8pm on Tuesday? If so, I'll email
you the Excel spreadsheets you need."
Until you get an answer to the question, you won't send the
spreadsheet.
An indirect synch is like that. When both synchronizers are running
and the dropboxes completely accesible to each other, the indirect
synch completes quickly, but in multiple stages. The simplest synch
is this:
1. Local drops MSG file in Remote dropbox requesting synch (and
giving details on local replica's synch generation).
2. Remote reads local's MSG file from remote dropbox.
3. Remote drops MSG file in local dropbox responding with its own
details.
4. Local reads MSG file in its dropbox and determines what it needs
to send. Local creates an MDB file in remote dropbox with data.
5. Remote reads MDB file in its dropbox, applies changes to its
replica and writes an MDB file in the local dropbox.
6. Local reads remote's MDB file from the local dropbox and applies
the changes from it to the local replica.
Steps 5-6 can repeat.
7. Local drops a "I'm done!" MSG file in remote dropbox.
8. Remote reads that MSG file and puts a "I'm done, too!" MSG file
in local dropbox.
It's only at this point that the synch is complete.
Steps 2-3 can't happen if the remote synchronizer isn't running, and
thus, step 4 can't happen until after steps 2-3. Not having both
synchronizers running simultaneously can vastly increase the amount
of time between initiating and completing an indirect synch.
>> - both synchronizers need to be able to write to each others'
>> dropbox (which is what the test above is for).
>
> They definitely can. I did the test you laid out and the
> permissions and connections are wide open.
Given that, I strongly suspect that the issues you are having are
due to 64-bit Windows and really don't know what to suggest.
>> I usually open both dropboxes when running a synch that I have
>> the time to observe, since I can then see the MSG files and MDB
>> files being created, opened (when the LDB appears for the MDB
>> files) and deleted.
>
> OK I'll do this also to monitor anything that (hopefully soon if I
> figure this out...) might be going on.
If you'll do this, you'll see the process happen, with MSG file in
one dropbox, MSG file in the other dropbox, then MDB in the first
dropbox, and then MDB file in the other, and so forth. It's how I
came to understand the process.
> I'm sure if I could get this
> to work even once and watch msg files being created and exchanged,
> I'd understand the process a whole lot better. As of yet though,
> I've had no success getting even of .msg file to appear. I'm
> going to have a party as soon as I see one appear. And free
> drinks for you!
You can put them in my dropbox. ;)
Anyway, I think the main issue is 64-bit Windows, and you need to be
sure that both the Jet synchronizer and the TSI Synchronizer are
running in the appropriate 32-bit environment and that they can
communicate with each other. I assume there's provision for all of
this, or 32-bit COM would completely break on 64-bit Windows, but I
don't know what you have to do to make it work.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
thanks for the info-packed reply...while I process all that, I have an
update & more questions:
I was able to get this to work one time. I watched the msg files &
mdb files get created on the remote dropbox after I executed an
indirect synch from the server to the laptop during lots of furious
testing. I celebrated briefly then tried to do it in reverse order
from the laptop to the server and it did not work. And now I can't
even get it to work from the server to the laptop again!
Here are my assumptions. Can you please tell me which are right/
wrong?
The key piece of info the local synchronizer needs in order to do an
indirect synch is the path of the dropbox of the remote replica it is
synchronizing with.
The dropbox address assigned to a specific replica is stored somewhere
in each replica file itself.
A replica's dropbox assignment can only be made behind the scenes via
a direct synch with the other computer or via a makereplica command.
The value of the remote dropbox location which is written into a
replica is pulled from the value of the registry's FSAddress string at
the time of the synch/makereplica.
I see lots of properties we can retrieve about replica members such
as: description, machine name, replica ID, replica name, synchronizer
ID, & UNC Name. But I don't see a way to retrieve the value of the
replica's dropbox location. Is this not the most important thing we'd
want to know for purposes of troubleshooting?
Is there a way to see what dropbox location is stored in a replica?
The oddest thing I see happening is that a sgn file is being created
in the replica's folder with the name of the replica as the name of
the file. Example: my local replica is c:\test\testrep. After an
[unsuccessful] indirect synch with a remote replica, there is a file
called testrep.sgn in the c:\test folder. The file is empty. This is
not supposed to happen, is it? Why would this happen?
Thanks so much for sticking with me on this....I really appreciate the
help.
|
|
leicklda <dkimbrell[ at ]wowway.com> wrote in
news:14145765-9812-4548-8c93-e5b0a1f18b91[ at ]z18g2000prn.googlegroups.co
m:
[Quoted Text] > thanks for the info-packed reply...while I process all that, I
> have an update & more questions:
>
> I was able to get this to work one time. I watched the msg files
> & mdb files get created on the remote dropbox after I executed an
> indirect synch from the server to the laptop during lots of
> furious testing. I celebrated briefly then tried to do it in
> reverse order from the laptop to the server and it did not work.
> And now I can't even get it to work from the server to the laptop
> again!
Hmm. That's odd. If each synchronizer can see and write to the other
synchronizer's dropbox, it should work regardless of which end it's
initiated from.
On the other hand, I've run onto scenarios when it did work reliably
only in one direction. I assume that server-iniated synchs are going
to be very rare, so you're really just concerned with
laptop-initiated synchs, so that's what you ought to concentrate on,
I think.
> Here are my assumptions. Can you please tell me which are right/
> wrong?
>
> The key piece of info the local synchronizer needs in order to do
> an indirect synch is the path of the dropbox of the remote replica
> it is synchronizing with.
Yes. The dropbox is the communication conduit.
> The dropbox address assigned to a specific replica is stored
> somewhere in each replica file itself.
Dropboxes are not assigned to replicas, but to synchronizers. For a
synchronizer, the only replicas that can be synched by that
synchronizer are the replicas that synchronizer manages.
> A replica's dropbox assignment can only be made behind the scenes
> via a direct synch with the other computer or via a makereplica
> command.
Er, what? Replicas don't have dropboxes -- synchonizers have
dropboxes. If you examine the MSysReplicas table, which records all
the information about all the replicas in your reploica set, you'll
see no column for dropbox (i.e., FS Address). You only see that in
the MSysTranspAddress table. I think that's short for "transporter,"
which, as you see from the name of the Jet synchronizer, is one of
the names for the synchronizer. Only managed replicas have a value
in the FSAddress field (here's a hint in dealing with the
replication system tables -- the fields are in alphabetical order,
left to right), while the unmanaged replicas have nothing in that
field.
> The value of the remote dropbox location which is written into a
> replica
There is no assocation between replicas and dropboxes, only between
synchronizers and dropboxes.
> is pulled from the value of the registry's FSAddress string at
> the time of the synch/makereplica.
An indirect synch is initiated by asking for communication between
synchronizers. Each synchronizer knows which replicas it manages,
and the synchronizer is the intermediary between the managed replica
and the remote synchronizer.
> I see lots of properties we can retrieve about replica members
> such as: description, machine name, replica ID, replica name,
> synchronizer ID, & UNC Name. But I don't see a way to retrieve
> the value of the replica's dropbox location. Is this not the most
> important thing we'd want to know for purposes of troubleshooting?
See above.
> Is there a way to see what dropbox location is stored in a
> replica?
You have to go through the managed replicas value stored in the
registry for the synchronizer to connect a replica with a
synchronizer. And you'll be able to do that only on the machine
where the replica is managed.
Now, once there have been successful indirect synchs, you'll then be
able to look in MSysExchangeLog and check the records that have FS
as the ActualTransportType value (i.e., that synch was done
indirect) in order to tell which replicas are managed by a
synchronizer. But that is only after-the-fact that you can find that
out.
> The oddest thing I see happening is that a sgn file is being
> created in the replica's folder with the name of the replica as
> the name of the file. Example: my local replica is
> c:\test\testrep. After an [unsuccessful] indirect synch with a
> remote replica, there is a file called testrep.sgn in the c:\test
> folder. The file is empty. This is not supposed to happen, is
> it? Why would this happen?
Hmm. I've never seen that. All I ever see is wingman.sgn, which is
the file created when the synchronizer is running (though it may
persist when the synchronizer is not running).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
All of your descriptions are a tremendous help, I can't thank you
enough for your time in explaining this so carefully. I'd been
reading conflicting descriptions of how things work. For example, the
TSI help files state "Whenever Microsoft Jet manages a replica, it
will write the location of its dropbox into the replica. ... You
notify other replicas of the new address, or dropbox, in one of two
ways: either you create a new replica from this managed replica, or
you synchronize with an existing replica. ". Maybe I'm reading this
in too simplified of a manner, but this states that the dropbox
location is stored in the replica. But I can see from the tables
(MSysTranspAddress and MSysReplicas) that as you say, a dropbox is
assigned to a synchronizer only, not a replica. These tables you
pointed out are my magic decoder ring to understanding the settings -
I didn't know about them. Thank you.
I still cannot get indirect replication to work, however!
Here is my scenario
Machine: boundarysys (server)
Synchronizer Name: boundarysys
Dropbox: "\\boundarysys\blinkdrop" - a shared folder. This location
is verified in both the registry and the MSysTranspAddress table
Replica managed by this synchronizer is: c:\testrep\version2.mdb (UNC
Name \\boundarysys\testrep\version2.mdb.) c:\testrep is not a shared
folder.
Machine: boundary18 (laptop)
Synchronizer Name: boundary18
Dropbox: "\\boundary18\bdrop" - a shared folder. This location is
verified in both the registry and the MSysTranspAddress table
Replica managed by this synchronizer is: c:\testrep\version4.mdb (UNC
Name \\boundary18\testrep\version4.mdb) c:\testrep is not a shared
folder
When I execute the following code from a front end interface on the
laptop:
Private Sub Command36_Click() 'indirect synch
Dim Synch As Synchronizer
Set Synch = New Synchronizer
Synch.Running = True
Synch.DatabaseName = "C:\testrep\version4.mdb"
Synch.SynchIndirect "{30070A82-D428-4110-8FFB-A391ECE26AA6}" 'this is
the repID of "\\boundarysys\testrep\version2.mdb"- I hardcoded it to
be sure it's the right one during testing.
Synch.Running = False
Set Synch = Nothing
End Sub
....the synchronizer starts, code flows right through the program lines
with no errors, and then the synchronizer closes. I am watching both
dropbox explorer windows at all times while running the code, and
there are no message files being created. I have verified that each
computer can write to the other's dropbox without any permissions
problems. All the obvious stuff is checked (like the replicas are in
the same replica set, etc...) I tried with the remote synchronizer
running, and with it not running.
I can use the synch.synchdirect and sych.makereplica commands with no
problem, so I think the synchronizer is setup correctly.
The only suspicious things I see are:
1. A version4.sgn file is created in the local c:\testrep folder.
This is an empty file.
2. The wingman.sgn file is created in the local dropbox folder, but
it is empty.
3. The fact that the server is 64 bit. This (I think) is causing one
difference: when I look at the transporter name of an unmanaged
replica on the server, there is an extra "box" character after the
name of the replica file. This box character is not present on the
laptop. Ex. TransporterDescription on server = "Unmanaged
'DMversion'**here's the box**on BOUNDARYSYS"
4. The ldb files of the replicas are never deleted after performing
any operations on them through the synch methods.
I realize you're kind of out of suggestions if this is related to a 64
bit issue, but I thought you might see some configuration error here
that I'm not seeing. I did get it to work ONE time, but have never
been able to reproduce that, so I think it must be a settings issue.
|
|
leicklda <dkimbrell[ at ]wowway.com> wrote in
news:97437ab2-537e-489b-9a18-3bbf102de5a2[ at ]c2g2000pra.googlegroups.com
:
[Quoted Text] > All of your descriptions are a tremendous help, I can't thank you
> enough for your time in explaining this so carefully. I'd been
> reading conflicting descriptions of how things work. For example,
> the TSI help files state "Whenever Microsoft Jet manages a
> replica, it will write the location of its dropbox into the
> replica. ...
Yes, but only for the *synchronizer*. The connection between a
synchronizer and a replica is nowhere found in the replica itself,
but is instead stored in the registry of the computer where the
synchronizer runs, and can be deduced from the MSysExchangeLog
table, which tells you which replicas you've synched with and how.
> You
> notify other replicas of the new address, or dropbox, in one of
> two ways: either you create a new replica from this managed
> replica, or you synchronize with an existing replica. ". Maybe
> I'm reading this in too simplified of a manner, but this states
> that the dropbox location is stored in the replica.
It is -- but it's not associated with a particular replica.
> But I can see from the tables
> (MSysTranspAddress and MSysReplicas) that as you say, a dropbox is
> assigned to a synchronizer only, not a replica. These tables you
> pointed out are my magic decoder ring to understanding the
> settings
Welcome to the Elect! That's how the rest of us figured it out
because the MS documentation has generally been pretty lacking.
> I didn't know about them. Thank you.
>
> I still cannot get indirect replication to work, however!
>
> Here is my scenario
>
> Machine: boundarysys (server)
> Synchronizer Name: boundarysys
> Dropbox: "\\boundarysys\blinkdrop" - a shared folder. This
> location is verified in both the registry and the
> MSysTranspAddress table Replica managed by this synchronizer is:
> c:\testrep\version2.mdb (UNC Name
> \\boundarysys\testrep\version2.mdb.) c:\testrep is not a shared
> folder.
>
> Machine: boundary18 (laptop)
> Synchronizer Name: boundary18
> Dropbox: "\\boundary18\bdrop" - a shared folder. This location is
> verified in both the registry and the MSysTranspAddress table
> Replica managed by this synchronizer is: c:\testrep\version4.mdb
> (UNC Name \\boundary18\testrep\version4.mdb) c:\testrep is not a
> shared folder
>
> When I execute the following code from a front end interface on
> the laptop:
>
> Private Sub Command36_Click() 'indirect synch
> Dim Synch As Synchronizer
> Set Synch = New Synchronizer
> Synch.Running = True
> Synch.DatabaseName = "C:\testrep\version4.mdb"
> Synch.SynchIndirect "{30070A82-D428-4110-8FFB-A391ECE26AA6}"
> 'this is the repID of "\\boundarysys\testrep\version2.mdb"- I
> hardcoded it to be sure it's the right one during testing.
> Synch.Running = False
> Set Synch = Nothing
> End Sub
Well, that won't work -- you need to synch with the SYNCHRONIZER, so
put the synchronizer name in place of the GUID.
> ...the synchronizer starts, code flows right through the program
> lines with no errors, and then the synchronizer closes. I am
> watching both dropbox explorer windows at all times while running
> the code, and there are no message files being created. I have
> verified that each computer can write to the other's dropbox
> without any permissions problems. All the obvious stuff is
> checked (like the replicas are in the same replica set, etc...)
> I tried with the remote synchronizer running, and with it not
> running.
I'm not sure exactly what's happening, but you shouldn't use a
ReplicaID, but either a synchronizer name or a synchronizer GUID.
> I can use the synch.synchdirect and sych.makereplica commands with
> no problem, so I think the synchronizer is setup correctly.
>
> The only suspicious things I see are:
> 1. A version4.sgn file is created in the local c:\testrep folder.
> This is an empty file.
It may or may not be empty -- if the file is open and not close, it
could show up as 0 bytes and if you open it show no contents, but
actually be a file with more content than that. The only way to know
would be to force quite the Jet synchronizer while it's open and
hope that the contents end up being written when it's closed. That
may or may not happen, and it could be that it's nothing but a
semaphore file, anyway, never intended to have any content.
> 2. The wingman.sgn file is created in the local dropbox folder,
> but it is empty.
This just shows that the synchronizer owns the dropbox. It doesn't
even tell you if the Jet synchronizer is running or not, as it's
left in the dropbox when the synchronizer shuts down.
> 3. The fact that the server is 64 bit. This (I think) is causing
> one difference: when I look at the transporter name of an
> unmanaged replica on the server, there is an extra "box" character
> after the name of the replica file. This box character is not
> present on the laptop. Ex. TransporterDescription on server =
> "Unmanaged 'DMversion'**here's the box**on BOUNDARYSYS"
Probably means nothing -- that's just a description field for the
end user.
> 4. The ldb files of the replicas are never deleted after
> performing any operations on them through the synch methods.
Hmm. That's interesting. The MDB they are associated with is
deleted? Very odd. Do you have admin permission on the server to see
who has the file open? Also, you might want to try something like
Process Explorer, which would allow you to see exactly which process
has the LDB file open.
> I realize you're kind of out of suggestions if this is related to
> a 64 bit issue, but I thought you might see some configuration
> error here that I'm not seeing. I did get it to work ONE time,
> but have never been able to reproduce that, so I think it must be
> a settings issue.
Try synching with a SYNCHRONIZER name, not a ReplicaID.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Success!
It's finally working. This would never have been possible without
your help, David. Thanks again. Look for some drinks in your
dropbox. :)
For others down the road who may struggle with this, here was my
biggest error: I was turning off the local synchronizer too soon.
The running of the synchronizer is a parallel activity outside of the
VB code that initiates it. That is, after the synchindirect method is
called, the synchronizer *starts* the process of synchronizing and two
activities diverge: 1. The VB code continues to the next line, and
2. The synchronizer continues to do it's process. VB doesn't
automatically know that the synchronizer is still running. So when
executed I these two lines consecutively,:
synch.synchindirect ()
synch.running = false
I was turning off the synchronizer a split second after it was
launched and effectively aborting the synchronization. The symptom of
this, other than non-functionality, was that a .sgn file with the name
of the database being replicated was sitting in the local database's
folder. This is the first file created in the synch process, and if
you abort the synch by turning off the synchronizer, this file will
just sit in the folder. But if you let the synch continue, you'll
see this file get deleted in a couple of seconds, and the .msg files
and .mdb files will start appearing and disappearing in the
dropboxes.
So it turns out to be on of David's "is it plugged in?" remedies. I
just didn't realize I was pulling the plug too soon b/c I thought the
code would only continue past the synchindirect method after it had
completed. I switched to the synchindirect2 method so I could monitor
the progress of the synchronizer and now I turn it off after the
synchronizer is done. Now the code does this:
synch.synchindirect2()
-loop through historyitems and determine when the synch is complete-
synch.running=false
I'm still tweaking. For example, the value of "completed" (2) is
triggering a couple seconds too early. And my local .ldb files are
not being deleted after the synch. I can work around these problems
though.
David you had said in one of your earlier replies that I should be
able to call the synchronizer by name: synch.synchindirect
("boundarysys"). This causes an error for me (operation failed). I
must refer to the synchronizer by ID in order for it to work. Do you
know why that might be?
Thanks again for all your help.
|
|
leicklda <dkimbrell[ at ]wowway.com> wrote in
news:c5491a58-4172-4140-8485-48fff036139a[ at ]z6g2000pre.googlegroups.com
:
[Quoted Text] > For others down the road who may struggle with this, here was my
> biggest error: I was turning off the local synchronizer too soon.
> The running of the synchronizer is a parallel activity outside of
> the VB code that initiates it. That is, after the synchindirect
> method is called, the synchronizer *starts* the process of
> synchronizing and two activities diverge: 1. The VB code
> continues to the next line, and 2. The synchronizer continues to
> do it's process. VB doesn't automatically know that the
> synchronizer is still running. So when executed I these two lines
> consecutively,:
>
> synch.synchindirect ()
> synch.running = false
>
> I was turning off the synchronizer a split second after it was
> launched and effectively aborting the synchronization. The
> symptom of this, other than non-functionality, was that a .sgn
> file with the name of the database being replicated was sitting in
> the local database's folder. This is the first file created in
> the synch process, and if you abort the synch by turning off the
> synchronizer, this file will just sit in the folder. But if you
> let the synch continue, you'll see this file get deleted in a
> couple of seconds, and the .msg files and .mdb files will start
> appearing and disappearing in the dropboxes.
>
> So it turns out to be on of David's "is it plugged in?" remedies.
Heh. It's so often the really simple and obvious things that are the
root causes.
I think I had suggested somewhere along the line that the only way
that the only way to tell if a synch has completed was via the
history object returned by SynchIndirect2, but I'm sure that was all
lost within a blizzard of details that didn't make it clear that you
should look at the original code.
Another solution you could use that doesn't involve the history
object is to create a loop that checks the STATUS field in
MSysExchangeHistory, but you'd have to know the ExchangeID to be
sure you're looking at the right record, and you can only get that
form the history object, so there's not all that much point in using
SynchIndirect2 to get the ExchangeID and then not using the same
history object's Status to determine if the synch has completed
(which is going to be querying the exact same value as you'd be
looking at in MSysExchangeHistory.Status).
> I
> just didn't realize I was pulling the plug too soon b/c I thought
> the code would only continue past the synchindirect method after
> it had completed.
The synchronizers can only work with each others' dropboxes when
they are running. I thought I'd explained that in my outline of what
happened during a synch, and why both synchronizers needed to be
running to finish the synch quickly.
> I switched to the synchindirect2 method so I could monitor
> the progress of the synchronizer and now I turn it off after the
> synchronizer is done. Now the code does this:
>
> synch.synchindirect2()
> -loop through historyitems and determine when the synch is
> complete- synch.running=false
You could do a:
Do Until _
tsiSynch.HistoryItemOfExchangeId(strExchangeID).SynchStatus > 1
Loop
You'd need to do this first:
strExchangeID = tsiSynch.SynchIndirect2([remote synchronizer])
in order for it to work, but it's the best way to do it.
> I'm still tweaking. For example, the value of "completed" (2) is
> triggering a couple seconds too early.
You actually need to be testing for >1, rather than for =2, because
there are other values, such as 3 (which means the synch failed and
has been permanently abandoned). You also might want to have a test
to see if it's 0 for a very long time, because, it's zero when the
synch is initiated (actually, when it's requested) and changes to 1
only after two-way communication with the other synchronizer has
been established. It then changes to something greater than 1 when
it has reached a completed state, either 2 for success or 3 for
failure.
> And my local .ldb files are
> not being deleted after the synch. I can work around these
> problems though.
I'm not sure why that would be if the MDBs associated with them are
being deleted.
> David you had said in one of your earlier replies that I should be
> able to call the synchronizer by name: synch.synchindirect
> ("boundarysys"). This causes an error for me (operation failed).
> I must refer to the synchronizer by ID in order for it to work.
> Do you know why that might be?
Hmm. The help file for the TSI Synchronizer says that it's not the
*synchronizer* name, but the *machine name* for a valid
synchronizer. That would only matter if you had named your
synchronizer something different from the machine it's on. If you
know the SynchronizerID, it's no big deal to use it. But keep in
mind that if you have to recreate the synchronizer on a machine, it
will end up with a different SynchronizerID, and that means that
your code will fail. If you use the machine name, the TSI
Synchronizer will look up the SynchronizerID for you, so I think
it's a better way to go.
Again, I'm glad you succeeded, and think it's great that the whole
history of your puzzling through it is here in this thread to help
other people who might encounter the same set of problems.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|