Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Error Reading File
Message
From
15/10/2016 12:27:59
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
15/10/2016 10:10:53
Thomas Ganss (Online)
Main Trend
Frankfurt, Germany
General information
Forum:
Visual FoxPro
Category:
Client/server
Environment versions
Visual FoxPro:
VFP 8 SP1
OS:
Windows Server 2016
Network:
Windows Server 2016
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01641841
Message ID:
01641988
Views:
57
>Directly opposite to the way I remember: Samba was the Unix implementation of SMB offering the same services through an offering with identical consonants for *x, as SMB had become the de-facto standard on PC hadware.

My memory has played weirder tricks on me before, so I wouldn't be surprised if I got it wrong here.

> MS had NetBios first defaulting to run over NetBEUI (AFAIR from WfW up to NT4 and W98, W2K I remember running here over TCP/IP but uncertain if I had to set it myself and very uncertain about the DOS drivers), which was ok on networks up to the # of human appendages.

W98 had tcp/ip, but by default it would still install NetBEUI unless you fiddled with the connection properties. Also not sure the tcp/ip was packaged by default but not set by default, or it was something to download. I do remember how NBeui became impossible to use when you add fourth or fifth machine, and then everything worked fine and fast when you switch to tcp/ip.

>Probably, but first Sambas had real problems with locking - which might have been a problem due to "sporadic" MS docs, which was one area MS was pressed, but I do not know if that was the source of that specific problem.

I think MS offered this way to connect to the unmentionable OSes as a concession to the masses, and then did it their own way - just good enough to prevent some 3rd party getting rich on selling a better alternative, yet never good enough to be reliable for serious work. And then when it finally got working right, they screwed it up, in such a way that it would be unreliable again, but not enough people would complain.

The problem, as stated in Tore's answer above, is that the ISAM tables tend to stay open for a long time, which is exactly what recent changes in the networking are against. It may just decide that the handle is hosed somehow, because it's been open for too long, here, I'll close that for you. I think such cases were reported already.

Which reminds me of the common practice back in the late nineties - when we had customers where someone else built and maintained the network. They'd do it the way they learned on M$'s courses or from their books or whatever. And when we had one of those "I've closed it for you" cases, we'd just complain, leave an explanation and full description of the problem and wait for those guys to check the network. And what would they do? They'd open and save a word document on another machine, i.e. checked that single writes work across the network. Handles being held for hours, file locking, record locking - that wasn't in their curriculum at all. And it seems that those problems have returned.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform