Hello again, John. Thanks a bunch for the reply.

>First an important point. Never use UNC paths with VFP. Always map the path to a
>drive letter. I can't tell you why but supposidly it runs faster with less errors.

Okay. Sounds good. If I had to guess, I'd say this has everything to do
with older DOS versions of FoxPro; that is, leftover code being reused
for backwards compatibility or something. OTOH, it could also be the
OS maybe? (Shrug!) :^)

>I would also suggest you share a folder off the host PC and not the entire drive
>then map a path to it.
>
>Create a folder like C:\APPS then place the shared table(s) in it.
>Then, from the other PC map a drive letter to it.
>I do it from the DOS prompt with:
>NET USE X: \\PROGRAMER1\APPS
>
>USE \\Programer1\documents\Rand_Sam\table1 SHARED
>Then becomes:
>use X:\Rand_Sam\table1

Okey doke. Good info, John.

>Next note: You do not need the SHARED keyword. All tables are shared by
>defualt unless you have change the default settings.

Okay.

>When updating a table I suggest using the SQL UPDATE command. It is fast and
>will do a lock before the update. If you are only adding records then there is no need >to do a lock before hand. See the SQL INSERT command for adding.

Okay. I printed this message out, gave it to Sameer, and he's making the
changes as I type. :^)

>As for VFP being multi-user it works very well and was designed that way from the
>start.

Hmmm. You have to wonder why MS promotes VB on the front-end and
SQL Server on the back-end instead of VFP? Hmmm. Because they make
more profit? :^)

>We have customers with 20 users banging away with table updates all day long and
>no problems. The .DBF tables somehow strongly resist corruption even when
>the power goes out with a bunch of people doing updates and the UPS battery
>on the server has been dead for 2 years!

This is nice to know! We've been wondering about this. As we speak,
this particular app is "in house only," so we'll gladly use VFP
database containers and tables. In the long run, though, this app
is going to the web via MySQL, so I guess we'll worry about those
pitfalls when cross that chasm.


>Most of what I have heard is that you are ok till you get past about 25 concurrent
>users.

Ahhh. Thus the difference between VFP and the VB, SQL-Sever combo.
I've also heard of the 25-user limit with MS Access. Fortunately,
I've never had the chance to run across these problems, which leads
me to a question.

When our apps start having 100+ users, should we be looking at the
"VB SQL Server" combo on an IBM Blade rack, or should we delve totally
into the "Linux, MySQL, and PHP" way of doing things. That is, why
throw away all of this Microsoft experience and training? Admittedly,
I'd love to see the "Linux, MySQL, and PHP" jump to the forefront,
but this is only because I'm familiar with those environments; however,
this kind of thinking could actually be a dis-service to my company
and users. I guess one has to think long and hard before making a final
decission on something like this. Personally, I'd totally hate being
a 100% Microsoft shop. Broad lattitude and flexibility is my name of
the game.

Thanks for the info, John. Much appreciated, dewd!

Randall