ASP.NET, SQL Server, WPF, C#, VB.NET

"JensB" <JensB@newsgroup.nospam> wrote in 
 
news:ehed8kItGHA.3264@TK2MSFTNGP03.phx.gbl: 
 
I think the two workgroup files might be to blame -- I can't figure 
 
out how you'd make the synchronizer work with two workgroup files, 
 
but I'm also drawing a blank in trying to determine in my head how 
 
the synchronizer relates to a workgroup file in the first place. 
 
The way I'd handle this would be to start all my replicated apps 
 
with one master workgroup file, then branch from that. That is, 
 
you'd have users and permissions specific to each workgroup, even 
 
though the administrative user in each would be the same one (not 
 
the built-in admin, of course). 
 
This is actually the way you really *ought* to do it, distributing 
 
to your users a workgroup file that completely lacks your custom 
 
administrative user. This makes it much more difficult to hack the 
 
workgroup file. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

Recently I had a post concerning,  if Replication manager synchronizer, 
 
could handles different replicaset at the same time.(Answer was yes) 
 
So now  the Synchronizser handles database  "Alfa" and "Bravo"secured with 
 
two different 
 
workgroup files: 
 
"Alfa" serves about 15 clients replicating 20-30 times daily.(Most clients 
 
uses Access 2000, and a few 2003 as BE) Have bee working for 3 years 
 
"Bravo" serves about 10 clients replicating 50 times daily.(All clients uses 
 
Access 2003 as BE) (6 month old) 
 
"Alfa" clients are using VB.NET 2003 (JRO) as FE 
 
"Bravo" clients are using using VB.NET 2005 (JRO) as FE 
 
All clients are running unmanaged. 
 
On the Windows 2003 server there is 4  managed Access 2000 databases as Hub 
 
farm. for "Alfa" and 4  managed Access 2000 databases as Hub farm for 
 
"Bravo" 
 
Replication worked fine at both databases for several weeks, 
 
Then only "Bravo" clients started to report this error: "Internal Internet 
 
Failure", 
 
and .tmp files start piling up in the dropbox on the server. 
 
Another post in this group, told me to look at permissions for the DrobBox 
 
folders, and I have checked 
 
that shared and NTFS folder system have all permissions necessary. 
 
"Bravo" Clients also report 100% CPU usage during the replication process, 
 
and also, that 1 out of 10 replication attempts succeed, and data is 
 
synchronised correctly to the server. 
 
"Bravo" database have been rebuild once, to eliminate if some corruption 
 
should bounce between replicaset, 
 
but error still remain. 
 
mstran40.exe, MSTRAI40.EXE and msrpfs40.dll are all version 4.0.6508.0 
 
I really hope that someone could point me to something, that could help this 
 
one out. 
 
Jens

"David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message 
 
news:Xns981163BAA96C0f99a49ed1d0c49c5bbb2@127.0.0.1... 
 
!!! Exact 
 
I just noticed 2 strange things, that could indicate something. 
 
A) 
 
In the replication manager synchronization history for the managed hub in 
 
"Bravo", 
 
in all lines the Status icon, and text is "In progress" , at the same time 
 
clients logfile report the above error. 
 
In those few occasions where replication succeed the Status icon, and text 
 
is "Completed" 
 
So it seems the synchronizer is hanging. 
 
As in the "Alfa" hub all lines are "Complete" 
 
B) 
 
On the server Windows\Temp folder at lot of Jetxxxxx.tmp files appears, 
 
first one for about 1½ month ago.(Same time when problems started) 
 
But the content doesn't look the same as those in the drop folder. 
 
In those in Temp folder I can se this text "Standard Jet DB" among the 
 
binary stuff. 
 
Jens

"JensB" <JensB@newsgroup.nospam> wrote in 
 
news:OTuPgdLtGHA.2260@TK2MSFTNGP02.phx.gbl: 
 
That's normal for any failed synch. 
 
I don't know that the TEMP folder is involved in indirect 
 
synchronization. The dropbox is where the files are, seems to me. 
 
However, perhaps Jet tmp files are created while the local 
 
synchronizer is applying the updates from the dropbox. You said 
 
you'd checked permissions on the dropbox (there can't be more than 
 
one), but did you check permissions on the folders that the managed 
 
replicas are in? If there were permissions prohibiting writes or 
 
deletions in that folder, that could be the cause of the failure. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

Managed hubs in "Bravo2" has the same permissions as "Alfa" 
 
Gave Windows\Temp folder same permissions as well. 
 
Still no positive result. 
 
One thing puzzles me, how is it possible to attach two different database to 
 
the same workgroupfile, 
 
or did I misunderstand you? 
 
Jens

"JensB" <JensB@newsgroup.nospam> wrote in 
 
news:e6XN2HVtGHA.1224@TK2MSFTNGP03.phx.gbl: 
 
[quoting me:] 
 
Are the two computers logged onto the same domain? If not, then how 
 
are you giving permission to the remote computer to the local 
 
dropbox? Using the EVERYONE group? You can also have a non-domain 
 
logon machine have the same username/password pair and that will 
 
work, too (though I'm not sure if the local user can be defined on 
 
the domain controller or if it has to be on the local machine; I've 
 
never done peer-to-peer with a domain on one end). 
 
Of course, the writing to the local replica should be done by the 
 
local synchronizer, which will inherit the permissions of the user 
 
whose session it is running in. 
 
The workgroup file has to be a superset of the two individual 
 
workgroups. You do it by creating a single workgroup file with a 
 
single administrator (not the default admin). Then you create two 
 
copies and add the groups and users appropriate to the two apps to 
 
each. If you're smart, you delete the custom administrator from the 
 
workgroup file you distribute to users. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

Hi David 
 
Thanks for being patient with me. 
 
No Clients belongs to the server domain, except my workstation. 
 
I made a new design master, hub and client replica, 
 
and connected them to the "Alfa"  workgroupfile. 
 
Then set it all up from start at the Replication manager. 
 
But 2 out of 10 replication gives still the above error. 
 
Could the problem be caused by some of the content of the database? 
 
there are about 1000 records in one table/column that contain WORD-OLE 
 
object. (50-100 Kb in size) 
 
Bigpost test with file sizes from 1 to 1.000.000 Kb runs ok. 
 
Jens

"JensB" <JensB@newsgroup.nospam> wrote in 
 
news:uFevQCvtGHA.2224@TK2MSFTNGP06.phx.gbl: 
 
Then I repeat the question: how are you giving permission to the 
 
remote logons to write to your dropbox? 
 
I don't recall the error that you're getting. 
 
I don't do Internet replication because I consider its dependence on 
 
IIS to be a ridiculously stupid design decision. Now that VPNs can 
 
be created by end users, I use Indirect replication over a VPN over 
 
the Internet to do remote synchs. So, any problems specific to 
 
Internet replication I can't advise on. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/