Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

losing data on a peer to peer net

0 views
Skip to first unread message

Rich Herbert

unread,
Apr 13, 1998, 3:00:00 AM4/13/98
to

I have an application that was running under PDX7-16bit on a WFW
network. We've started making the transition to a fileserver but aren't
there yet. In the interim we have connected an NT4.0 machine and a
Win95 machine together. I've installed pdx7-32bit on each of the
machines along with the v7 patch. The database resides on the Win95
machine. If just one machine is accessing the database then everything
is okay. When both machines try to access the database newly entered
records are lost. At first I thought it was an outdated BDE (it's dated
2/6/97) but that doesn't seem to be the problem. Is this a pdox issue
or a Win95/Win NT issue? All of my other pdox apps are running great on
Novell servers and this is the first time I've tried to run anything
peer-to-peer. Is anyone else running peer-to-peer? What am I missing?!

TIA,
Rich


--
_____________________________________________________
Rich Herbert Skyridge Design Team
ri...@skyridgedesign.com Indianapolis, IN
Database Development (317) 578-9298
General Consulting <>< fax 595-9298
_____________________________________________________

Alexander Philippou

unread,
Apr 14, 1998, 3:00:00 AM4/14/98
to

Rich Herbert <ri...@skyridgedesign.com> wrote in article
<353258...@skyridgedesign.com>...

> I have an application that was running under PDX7-16bit on a WFW
> network.
> snip

> If just one machine is accessing the database then everything
> is okay. When both machines try to access the database newly entered
> records are lost.

Set the Local Share in the BDE to True.

Alexander Philippou
al...@noemon.com

David Topps

unread,
Apr 18, 1998, 3:00:00 AM4/18/98
to

I have had a similar problem when trying to run PDX5 or PDX7 record locking
under 32 bit W95 - record locking does not work and overwrites are not
protected. The only solution that I have found is to put the shared tables
onto Win3.11 ie 16 bit - numerous previous questions never did produce any
other answer. Will this fix help with the 32 bit problem too?

I hope so but am leary to try it since I have previously corrupted some
tables messing around with this.


Alexander Philippou wrote in message
<01bd6761$0a8c56e0$aec2...@merlin.hol.gr>...

Kirk Dickinson

unread,
Apr 18, 1998, 3:00:00 AM4/18/98
to

Rich,

I have been through all the headaches of peer to peer data corruption.
There was only one solution that finally put an end to it happening all the
time.

You have to have your Net lock directory pointed to the EXACT SAME Physical
location and use the SAME EXACT name for that location on every peer.

In other words lets say that you have three computers named Bob, Joe and
Sam and you have the netlock directory on the "Bob" "C" drive in a directory
called "netfiles". Now normal logic would say that on Joe and Sam you map
the Bob D drive to a new drive letter and point the net dir there. That
won't work because even if you map it to the same letter on Joe and Sam, it
will still be "C" on Bob and the EXACT won't be achieved.

Here is what I would do. In the Net Dir setting, use the network path
unstead of a mapped drive letter. So it would be NET DIR:
\\Bob\c\netfiles

If it is mapped that way in all your computers, I will nearly guarantee that
your data corruption will become a thing of the past. This problem has been
there since version 5 and they still haven't fixed it.

Don't believe me? Give it a try, you don't have anything to loose at this
point.

Of course, you probably already have all your local share set to True which
you also need.

Kirk

Rich Herbert wrote in message <353258...@skyridgedesign.com>...


>I have an application that was running under PDX7-16bit on a WFW

>network. We've started making the transition to a fileserver but aren't
>there yet. In the interim we have connected an NT4.0 machine and a
>Win95 machine together. I've installed pdx7-32bit on each of the
>machines along with the v7 patch. The database resides on the Win95

>machine. If just one machine is accessing the database then everything


>is okay. When both machines try to access the database newly entered

so...@spamlesssoleassociates.com

unread,
Apr 19, 1998, 3:00:00 AM4/19/98
to

"Kirk Dickinson" <long...@rmi.net> wrote:

»Rich,


»
»I have been through all the headaches of peer to peer data corruption.
»There was only one solution that finally put an end to it happening all the
»time.
»
»You have to have your Net lock directory pointed to the EXACT SAME Physical
»location and use the SAME EXACT name for that location on every peer.
»
»In other words lets say that you have three computers named Bob, Joe and
»Sam and you have the netlock directory on the "Bob" "C" drive in a directory
»called "netfiles". Now normal logic would say that on Joe and Sam you map
»the Bob D drive to a new drive letter and point the net dir there. That
»won't work because even if you map it to the same letter on Joe and Sam, it
»will still be "C" on Bob and the EXACT won't be achieved.
»
»Here is what I would do. In the Net Dir setting, use the network path
»unstead of a mapped drive letter. So it would be NET DIR:
»\\Bob\c\netfiles
»
»If it is mapped that way in all your computers, I will nearly guarantee that
»your data corruption will become a thing of the past. This problem has been
»there since version 5 and they still haven't fixed it.
»
»Don't believe me? Give it a try, you don't have anything to loose at this
»point.
»
»Of course, you probably already have all your local share set to True which
»you also need.
»
»Kirk

»
Hi Kirk,

I am trusting my (ever more feeble) memory on this, but thought
that I had trouble a while back trying just what you suggest. If
I remember correctly, it worked fine on all systems but the one
with the net files. On Bob's machine, the \\Bob\c\netfiles format
was rejected by the BDE.
-
Kenneth

peter

unread,
Apr 20, 1998, 3:00:00 AM4/20/98
to

Any further comment on this issue?

David Topps <to...@acs.ucalgary.ca> wrote in article
<6hasqm$9...@priv-sys04-le0.agt.net>...

0 new messages