Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Files for ServerComputer
Message
From
25/08/2023 00:00:34
Lutz Scheffler (Online)
Lutz Scheffler Software Ingenieurbüro
Dresden, Germany
 
 
To
24/08/2023 16:17:28
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
01686954
Message ID:
01686977
Views:
40
This was understood.
Let me point out again why one should not do this.

LAN stored DBF
A table (that means, it's parts DBF/CDX/FPT) files is stored on the network. While access via network look like access from your local drives it is not. The locking and caching work different, since the data access is scattered in the network and the comp with VFP has no control.
As soon as the second comp opens a table, the table is no longer cached in your comp, and therefore reared every time you use or requery your view. And, since you work concurrent, you must requery. On this is slooow. You will not notice if you work alone - then it is cached. And however fast your network is, your local drives are faster. Also you need to keep the network alive all time long, any little failure might corrupt your data. And I do not stored the problems with data accessible for everybody via the network share, problems with time sync (a small diff on two comps makes timestamps unreliable)
A SQL Server will solve all those problems, and there are enough free ones.

Views
The local view deals with VFP tables, a remote view with a SQL Server (not only MS branded). Both are outdated and hard to maintain. The main problem is, there is no good way to control them aside endless lines of CURSORSETPROP and they are stored in the DBC. To change a view, you must change the DBC. What btw, bloats the database. Learn the use of Cursoradapter, it does basically the same for data handling while much more easy to maintain - to change one just need to role out code, and not code + manipulating the database. And a CA is more easy to rework, if on switches from VFP data to SQL Server.


>my intent was to only use dbfs in the dbc and use either local views or remote views into them with records lock.
>
>>Then a lousy 10a old PC with a LINUX with some SQL there. Find a volunteer to set it up. The critical mass on shared DBF is 2 users. Aside all the access problems. I only can discourage you.
>>
>>Thank you Lutz et al.
>>>
>>>This is a very small organization. Definitely do not have the budget or moolah to purchase SQL lite or anything that rhymes with SQL. Just trying to provide them with some database application to assist in managing some of their assets and resources on a regular basis, again, small mom-pop setup with about 4 employees of caterers and event planners.
>>>
>>>>>Howdy,
>>>>>
>>>>>Have a potential client that is wanting to have a central database for all his employees to have access to via an application I'm develping. What files do I need to ensure I load on the designated "server" computer /main computer. I'm guessing one file in particular would be a separate project file that only has the dbc??
>>>>>
>>>>>Thanks in Advance....
>>>>
>>>>Views / CA over network to a shared folder will work - somehow. It needs to transport the data along the network, and as soon as more then one access the same table, VFP tends to move the whole data (table, memo and index) on every requery. We skipped the idea for decades and run on terminal services. Much faster, no network fuzz.
>>>>Or use some SQL Server (something on a LINUX will do, no need to feed M$ ) that provides you with the data. Much less data transfer.
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord

Weeks of programming can save you hours of planning.

Off

There is no place like [::1]
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform