Hi all!

The last 20 years we work allmost all our apps over MS SQL , so my DBF experiance is really small..

We have a DBF/CDX app that deals with Mechanical Projects financial control. It has some DBF's that deal with work details (something like timesheets for workers), that we have to summarize when entering the project window.

Of course this should be built in SQL but for legacy reasons it still stands with DBF/CDX.

Sudently a new customer - with 3-4 users over network started complaining for bid delays WHEN A SECOND USER WAS USING THES PROGRAMM!.

We tried to reproduced in our office and were astonished to find out that a typical DO WHILE inside a scope containing 2800 records (we use the proper index of course) was taking:

- 0,5 seconds when only one user runs the programm
- 24 seconds when another user uses the files froma another workstation

Is this as expected?? Do I miss something??

Any ideas appreciated.

Stavros

Dear Stavros Spanos:

On Wednesday, March 8, 2023 at 6:57:45 AM UTC-7, Stavros Spanos wrote:
....
> Is this as expected?? Do I miss something??

It is in ways like this that Micro$haft has been forcing Windoze users to have Windoze server software, and centralized data servers. And to inflate their apparent performance against Linux too of course.

There are some patches in the registry you need to implement having to do with caching and locks. Hopefully someone on here knows what needs to happen in VO-ese (I do xHarbour, so...). But the average desktop is not set up to have multiple pathways for data to pass over ethernet. And if some of these users are using WiFi, this is even more chances for things to break and damage files.

What might be easiest / fastest is to have a central computer do the DBF/CDX stuff, and supply users with Terminal services... essentially "remote desktop" type interfacing.

If the data tables are "read only", maybe just have local copies of them on each machine. Remember that peer-to-peer networks require every byte of data (at least for indexes) be passed up to multiple times across the network from the host machine. Elegant commands "server find something" devolves to "Send me this entire file so I can find something I need in it."

David A. Smith

Move to VM or SQL.. as this the DBF killer with throttle performance
Might have been on Windows 7 and moved to 10 or 11

Never found LAN solution that worked.

Phil

Phil - and all!

Thanks a lot for the feedback. What do you mean "move to VM??"

On Thursday, March 9, 2023 at 6:49:59 AM UTC-7, Stavros Spanos wrote:
> Phil - and all!
>
> Thanks a lot for the feedback. What do you mean "move to VM??"

Virtual Machine, aka. Terminal Services... just one 'brand name' or another..

David A. Smith

Stavros..

Few options you have with legacy DBF systems.. I still have about 80 clients runniing VO + DBF on premises.
They a not the biggest clients anymore so they are fine with the "throtted' connection speed with SMB doing this.
First connection to DBF full speed, 2nd or 3rd etc.. OS throttles the bandwidth

You read about how it works and attempts to control it
https://woshub.com/limit-network-file-transfer-speed-windows/

I never found a total solution for the SML issue.
We want to move away from change OS and dealing with IT guys.

2 most common options..... for DBF legacy

We moved many 100's of clients onto VMs [ Virtual Machines ]
Some internally and most into Cloud. Very successful for many reasons.
We own a lot of HP Hosts and can run 10 to 30 companies on a HOST
We developed our own 2FA so we do not have lock down to fixed IPS
We roll out say Windows 2016 VM and copy all our systems to it.. the use RPD to run it.
The clients were going to lose to Browser based systems happy it all works.
Could have used CONTAINERS for the HOST , just never got around to it.

We developed about 9 years ago a SQL replacement for DBF.. GOod move.
Used Postgres SQL and this could remain on-premises or in VM

The browser cloud version as in PHP / Wordpress / Postgres SQL wil remove VO version.
This is close in development and for later this year. But once you go this way a whole new world.
Interfacing to say 40 APIS and other integrated cloud solutions.

We wrote the VO replacement in Delphi and it currently being ported to Delphi .NET
THe reason being as we replace VO with XSHARP in NET the other code will be .NET as well.
We will move all the POSTGRES back end out of VM to Amazon or Azure or Google or other

The world is a changing rapidly to trusted big end cloud systems.

Email now using "Socketlabs" for all delivery for my customers. Great product.
Where once we had the SMTP server.. More and more old ideas and ways are going

Hi Stavros,

We only develop apps with DBF/CDX and have done so since the late 80's.
We find it so flexible and can do practically anything that is needed.

The majority of our multi-user clients from around the world have moved their data from in-house servers over a lan (yes slow) - onto the cloud with virtual servers and there are no speed issues via RDP and they simply use published apps - so fast, secure and definitely the way to go! Your problem will be solved.

Other benefits include the ability to run the software on any smart device be they Windows / IOS / Android based systems (phones, laptops, pcs, tablets, etc) from anywhere in the world. Customer's operating systems don't matter anymore these days - VO apps run fine on all of them :)

Snip[ speed issues via RDP and they simply use published apps - so fast, secure and definitely the way to go! Your problem will be solved. ]

ManageAPP is still RDP.. just that your access is to the app than than the desktop.

VM / Contaiiners / RDP is way to expose VO or other windows apps / desktop for clients.
Been doing this for maybe 15 years..

But despite this Browser systems,, totally dominating the development arena.

Phil

THE SOLUTION

(I’m talking loud to myself, as though you hinted to it somehow I didn’t get it at first..)

Well just tested that if we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users.

On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them. The reasons for this are well described on this thread.

Thanks all for your thoughts and help!

Stavros

snip[ f we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users. ]

Lets 100% clarify exactly what we are saying. RPD [ remote desktop protocol ] which could be an Apple, Linux and Windows is communication protocol one machine to another.
They do not need Windows on the machines connecting, just a RDP client.
Your programs and data are running / available via the Terminal Server HOST.. The machines connecting via RPD is are not 'natively" running your program.
Each view of a windows desktop [ or managed app ] is really a "view" of the ONE PC [ the server ].
You might have 5 users, your program is running 5 times on the ONE PC. So it needs to have the resources for this RAM, DISK and CPU

snip[ ... On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them.]

Where clients notice quickly if they move from Windows 7 to 10 and then the "throttling" so it is not just a shared situation. This SMB 1 to 3.
We had so many hit this wall and could not the system efficiently.
I could get around SMB1 but the later, they use Port135 and if you shut this down have other issues.
So when say Windows 10/11 opens says DBF/FPT for one connection, 1 user and another user another machine connects the SMB "throttles" the access.
But with SQL this does not happen as you are connecting to SQL engine that controls all the connections. The other is via the OS direct and BAM. [ Block Availabiliy Map]
The locking and unlocking happens there. When you connect to say DBF/FPT it sees host of different machines and users and throttles access speeds.

Taking this all in..... the Terminal Server [ or clones ] owns all the connections, one super client best way to describe it.
Your customer/ clients / users using RPD to run programs are not throtted because the server is not really dealing with you, but the TS.

For Craig and I am different ways kept these VO apps and DBF operational for clients to stop the massive move to cloud.
My situation is different as all my competitors which were not cloud have been eliminated.
The VM strategy has allowed me to keep 100 clients that I would have lost.
With all these web cloud hack attacks...... a VM is the best security.
We developed our own 2FA with controls into the VM and users.

But saying all that, it does not win all battles. Have a lot of younger clients, browser or nothing.
End of 2023 our 100% cloud version will go to market and over time these VM clients will eventually be phased out.
A PHP and Wordpress front end to same SQL and business logic and reports.
But this will be their choice. All our "non legacy" development is SQL. No ongoing DBF development.
We use Postgres or mySQL depending on the market. The learning curve of SQL is well worth the journey.
Work with a lot of SQL gurus and we can do amazing things easily and a DBF is hard work.

With JSON beiing a major data interchange these days, this is natively supported in SQL.
Drop it in, query and refactor with a query. That is you do not have to create temp tables or miriad of fields for data then convert backwards and forwards.
Native means it fully knows how to work with it..

DBF just never designed for this. But a good simple structure will minimal field types.
DBF say NDLCOM 6 types and SQL like 56 if you want to go that far.

To move clients from DESKTOP ... to say VM we rollout a VM on our own servers hosts [ have many ]
Allocate an IP we spend day or 5 copying existing over.. they can keep working.
We setup the new shortcuts for RPD.. some minimal training, user access and levels.
On the day of full change over we sync any changes and they go live.
We leave existing system there for 90 days just in case we missed something..
THen they delete the old system,
We take over the backups.

Mention if you have an IT company that does this Containers maybe better for space.
Each VM is a full operating system. We have HOST and might have 20 VMS. So 21 OS on that box.

A container is alike VM without an operating system, it uses the HOSTS OS.
Never had the time to experiement with it but could save a lot of space.

Phil McGuinness
------------

> THE SOLUTION
>
> (I’m talking loud to myself, as though you hinted to it somehow I didn’t get it at first..)
>
> Well just tested that if we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users.
>
> On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them. The reasons for this are well described on this thread.
>
> Thanks all for your thoughts and help!

Hi Stravos,

we have make a tool/RDD for to migrate from DBF to MySQL.
This RDD has some limit but work well and fast.

Contact me if you are interested.

Alessandro

Il giorno sabato 1 aprile 2023 alle 03:20:19 UTC+2 Phil McGuinness ha scritto:
> Stavros
>
> snip[ f we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users. ]
>
> Lets 100% clarify exactly what we are saying. RPD [ remote desktop protocol ] which could be an Apple, Linux and Windows is communication protocol one machine to another.
> They do not need Windows on the machines connecting, just a RDP client.
> Your programs and data are running / available via the Terminal Server HOST. The machines connecting via RPD is are not 'natively" running your program.
> Each view of a windows desktop [ or managed app ] is really a "view" of the ONE PC [ the server ].
> You might have 5 users, your program is running 5 times on the ONE PC. So it needs to have the resources for this RAM, DISK and CPU
>
> snip[ ... On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them.]
>
> Where clients notice quickly if they move from Windows 7 to 10 and then the "throttling" so it is not just a shared situation. This SMB 1 to 3.
> We had so many hit this wall and could not the system efficiently.
> I could get around SMB1 but the later, they use Port135 and if you shut this down have other issues.
> So when say Windows 10/11 opens says DBF/FPT for one connection, 1 user and another user another machine connects the SMB "throttles" the access.
> But with SQL this does not happen as you are connecting to SQL engine that controls all the connections. The other is via the OS direct and BAM. [ Block Availabiliy Map]
> The locking and unlocking happens there. When you connect to say DBF/FPT it sees host of different machines and users and throttles access speeds.
>
> Taking this all in..... the Terminal Server [ or clones ] owns all the connections, one super client best way to describe it.
> Your customer/ clients / users using RPD to run programs are not throtted because the server is not really dealing with you, but the TS.
>
> For Craig and I am different ways kept these VO apps and DBF operational for clients to stop the massive move to cloud.
> My situation is different as all my competitors which were not cloud have been eliminated.
> The VM strategy has allowed me to keep 100 clients that I would have lost..
> With all these web cloud hack attacks...... a VM is the best security.
> We developed our own 2FA with controls into the VM and users.
>
> But saying all that, it does not win all battles. Have a lot of younger clients, browser or nothing.
> End of 2023 our 100% cloud version will go to market and over time these VM clients will eventually be phased out.
> A PHP and Wordpress front end to same SQL and business logic and reports.
> But this will be their choice. All our "non legacy" development is SQL. No ongoing DBF development.
> We use Postgres or mySQL depending on the market. The learning curve of SQL is well worth the journey.
> Work with a lot of SQL gurus and we can do amazing things easily and a DBF is hard work.
>
> With JSON beiing a major data interchange these days, this is natively supported in SQL.
> Drop it in, query and refactor with a query. That is you do not have to create temp tables or miriad of fields for data then convert backwards and forwards.
> Native means it fully knows how to work with it..
>
> DBF just never designed for this. But a good simple structure will minimal field types.
> DBF say NDLCOM 6 types and SQL like 56 if you want to go that far.
>
> To move clients from DESKTOP ... to say VM we rollout a VM on our own servers hosts [ have many ]
> Allocate an IP we spend day or 5 copying existing over.. they can keep working.
> We setup the new shortcuts for RPD.. some minimal training, user access and levels.
> On the day of full change over we sync any changes and they go live.
> We leave existing system there for 90 days just in case we missed something.
> THen they delete the old system,
> We take over the backups.
>
> Mention if you have an IT company that does this Containers maybe better for space.
> Each VM is a full operating system. We have HOST and might have 20 VMS. So 21 OS on that box.
>
> A container is alike VM without an operating system, it uses the HOSTS OS..
> Never had the time to experiement with it but could save a lot of space.
>
> Phil McGuinness
> ------------
> > THE SOLUTION
> >
> > (I’m talking loud to myself, as though you hinted to it somehow I didn’t get it at first..)
> >
> > Well just tested that if we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users.
> >
> > On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them. The reasons for this are well described on this thread.
> >
> > Thanks all for your thoughts and help!

Hi Alessandro,
I'm intrested in your tool, can you give me more information?

Regards
Gianluca Pinoli

Il giorno martedì 4 aprile 2023 alle 09:57:30 UTC+2 Alessandro Vacchiano ha scritto:
> Hi Stravos,
>
> we have make a tool/RDD for to migrate from DBF to MySQL.
> This RDD has some limit but work well and fast.
>
> Contact me if you are interested.
>
> Alessandro
> Il giorno sabato 1 aprile 2023 alle 03:20:19 UTC+2 Phil McGuinness ha scritto:
> > Stavros
> >
> > snip[ f we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users. ]
> >
> > Lets 100% clarify exactly what we are saying. RPD [ remote desktop protocol ] which could be an Apple, Linux and Windows is communication protocol one machine to another.
> > They do not need Windows on the machines connecting, just a RDP client.
> > Your programs and data are running / available via the Terminal Server HOST. The machines connecting via RPD is are not 'natively" running your program.
> > Each view of a windows desktop [ or managed app ] is really a "view" of the ONE PC [ the server ].
> > You might have 5 users, your program is running 5 times on the ONE PC. So it needs to have the resources for this RAM, DISK and CPU
> >
> > snip[ ... On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them.]
> >
> > Where clients notice quickly if they move from Windows 7 to 10 and then the "throttling" so it is not just a shared situation. This SMB 1 to 3.
> > We had so many hit this wall and could not the system efficiently.
> > I could get around SMB1 but the later, they use Port135 and if you shut this down have other issues.
> > So when say Windows 10/11 opens says DBF/FPT for one connection, 1 user and another user another machine connects the SMB "throttles" the access.
> > But with SQL this does not happen as you are connecting to SQL engine that controls all the connections. The other is via the OS direct and BAM. [ Block Availabiliy Map]
> > The locking and unlocking happens there. When you connect to say DBF/FPT it sees host of different machines and users and throttles access speeds.
> >
> > Taking this all in..... the Terminal Server [ or clones ] owns all the connections, one super client best way to describe it.
> > Your customer/ clients / users using RPD to run programs are not throtted because the server is not really dealing with you, but the TS.
> >
> > For Craig and I am different ways kept these VO apps and DBF operational for clients to stop the massive move to cloud.
> > My situation is different as all my competitors which were not cloud have been eliminated.
> > The VM strategy has allowed me to keep 100 clients that I would have lost.
> > With all these web cloud hack attacks...... a VM is the best security.
> > We developed our own 2FA with controls into the VM and users.
> >
> > But saying all that, it does not win all battles. Have a lot of younger clients, browser or nothing.
> > End of 2023 our 100% cloud version will go to market and over time these VM clients will eventually be phased out.
> > A PHP and Wordpress front end to same SQL and business logic and reports.
> > But this will be their choice. All our "non legacy" development is SQL. No ongoing DBF development.
> > We use Postgres or mySQL depending on the market. The learning curve of SQL is well worth the journey.
> > Work with a lot of SQL gurus and we can do amazing things easily and a DBF is hard work.
> >
> > With JSON beiing a major data interchange these days, this is natively supported in SQL.
> > Drop it in, query and refactor with a query. That is you do not have to create temp tables or miriad of fields for data then convert backwards and forwards.
> > Native means it fully knows how to work with it..
> >
> > DBF just never designed for this. But a good simple structure will minimal field types.
> > DBF say NDLCOM 6 types and SQL like 56 if you want to go that far.
> >
> > To move clients from DESKTOP ... to say VM we rollout a VM on our own servers hosts [ have many ]
> > Allocate an IP we spend day or 5 copying existing over.. they can keep working.
> > We setup the new shortcuts for RPD.. some minimal training, user access and levels.
> > On the day of full change over we sync any changes and they go live.
> > We leave existing system there for 90 days just in case we missed something.
> > THen they delete the old system,
> > We take over the backups.
> >
> > Mention if you have an IT company that does this Containers maybe better for space.
> > Each VM is a full operating system. We have HOST and might have 20 VMS. So 21 OS on that box.
> >
> > A container is alike VM without an operating system, it uses the HOSTS OS.
> > Never had the time to experiement with it but could save a lot of space..
> >
> > Phil McGuinness
> > ------------
> > > THE SOLUTION
> > >
> > > (I’m talking loud to myself, as though you hinted to it somehow I didn’t get it at first..)
> > >
> > > Well just tested that if we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users.
> > >
> > > On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them. The reasons for this are well described on this thread.
> > >
> > > Thanks all for your thoughts and help!

Gianluca write me an email at alessandro@computerscenter.com

Bye

Il giorno mercoledì 5 aprile 2023 alle 11:24:15 UTC+2 Gianluca ha scritto:
> Hi Alessandro,
> I'm intrested in your tool, can you give me more information?
>
> Regards
> Gianluca Pinoli
> Il giorno martedì 4 aprile 2023 alle 09:57:30 UTC+2 Alessandro Vacchiano ha scritto:
> > Hi Stravos,
> >
> > we have make a tool/RDD for to migrate from DBF to MySQL.
> > This RDD has some limit but work well and fast.
> >
> > Contact me if you are interested.
> >
> > Alessandro
> > Il giorno sabato 1 aprile 2023 alle 03:20:19 UTC+2 Phil McGuinness ha scritto:
> > > Stavros
> > >
> > > snip[ f we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users. ]
> > >
> > > Lets 100% clarify exactly what we are saying. RPD [ remote desktop protocol ] which could be an Apple, Linux and Windows is communication protocol one machine to another.
> > > They do not need Windows on the machines connecting, just a RDP client.
> > > Your programs and data are running / available via the Terminal Server HOST. The machines connecting via RPD is are not 'natively" running your program.
> > > Each view of a windows desktop [ or managed app ] is really a "view" of the ONE PC [ the server ].
> > > You might have 5 users, your program is running 5 times on the ONE PC.. So it needs to have the resources for this RAM, DISK and CPU
> > >
> > > snip[ ... On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them.]
> > >
> > > Where clients notice quickly if they move from Windows 7 to 10 and then the "throttling" so it is not just a shared situation. This SMB 1 to 3.
> > > We had so many hit this wall and could not the system efficiently.
> > > I could get around SMB1 but the later, they use Port135 and if you shut this down have other issues.
> > > So when say Windows 10/11 opens says DBF/FPT for one connection, 1 user and another user another machine connects the SMB "throttles" the access..
> > > But with SQL this does not happen as you are connecting to SQL engine that controls all the connections. The other is via the OS direct and BAM. [ Block Availabiliy Map]
> > > The locking and unlocking happens there. When you connect to say DBF/FPT it sees host of different machines and users and throttles access speeds.
> > >
> > > Taking this all in..... the Terminal Server [ or clones ] owns all the connections, one super client best way to describe it.
> > > Your customer/ clients / users using RPD to run programs are not throtted because the server is not really dealing with you, but the TS.
> > >
> > > For Craig and I am different ways kept these VO apps and DBF operational for clients to stop the massive move to cloud.
> > > My situation is different as all my competitors which were not cloud have been eliminated.
> > > The VM strategy has allowed me to keep 100 clients that I would have lost.
> > > With all these web cloud hack attacks...... a VM is the best security..
> > > We developed our own 2FA with controls into the VM and users.
> > >
> > > But saying all that, it does not win all battles. Have a lot of younger clients, browser or nothing.
> > > End of 2023 our 100% cloud version will go to market and over time these VM clients will eventually be phased out.
> > > A PHP and Wordpress front end to same SQL and business logic and reports.
> > > But this will be their choice. All our "non legacy" development is SQL. No ongoing DBF development.
> > > We use Postgres or mySQL depending on the market. The learning curve of SQL is well worth the journey.
> > > Work with a lot of SQL gurus and we can do amazing things easily and a DBF is hard work.
> > >
> > > With JSON beiing a major data interchange these days, this is natively supported in SQL.
> > > Drop it in, query and refactor with a query. That is you do not have to create temp tables or miriad of fields for data then convert backwards and forwards.
> > > Native means it fully knows how to work with it..
> > >
> > > DBF just never designed for this. But a good simple structure will minimal field types.
> > > DBF say NDLCOM 6 types and SQL like 56 if you want to go that far.
> > >
> > > To move clients from DESKTOP ... to say VM we rollout a VM on our own servers hosts [ have many ]
> > > Allocate an IP we spend day or 5 copying existing over.. they can keep working.
> > > We setup the new shortcuts for RPD.. some minimal training, user access and levels.
> > > On the day of full change over we sync any changes and they go live.
> > > We leave existing system there for 90 days just in case we missed something.
> > > THen they delete the old system,
> > > We take over the backups.
> > >
> > > Mention if you have an IT company that does this Containers maybe better for space.
> > > Each VM is a full operating system. We have HOST and might have 20 VMS. So 21 OS on that box.
> > >
> > > A container is alike VM without an operating system, it uses the HOSTS OS.
> > > Never had the time to experiement with it but could save a lot of space.
> > >
> > > Phil McGuinness
> > > ------------
> > > > THE SOLUTION
> > > >
> > > > (I’m talking loud to myself, as though you hinted to it somehow I didn’t get it at first..)
> > > >
> > > > Well just tested that if we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users.
> > > >
> > > > On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them. The reasons for this are well described on this thread.
> > > >
> > > > Thanks all for your thoughts and help!

On Wednesday, 5 April 2023 at 9:49:42 pm UTC+10, Alessandro Vacchiano wrote:
> Gianluca write me an email at aless...@computerscenter.com
>
> Bye
> Il giorno mercoledì 5 aprile 2023 alle 11:24:15 UTC+2 Gianluca ha scritto:
> > Hi Alessandro,
> > I'm intrested in your tool, can you give me more information?
> >
> > Regards
> > Gianluca Pinoli
> > Il giorno martedì 4 aprile 2023 alle 09:57:30 UTC+2 Alessandro Vacchiano ha scritto:
> > > Hi Stravos,
> > >
> > > we have make a tool/RDD for to migrate from DBF to MySQL.
> > > This RDD has some limit but work well and fast.
> > >
> > > Contact me if you are interested.
> > >
> > > Alessandro
> > > Il giorno sabato 1 aprile 2023 alle 03:20:19 UTC+2 Phil McGuinness ha scritto:
> > > > Stavros
> > > >
> > > > snip[ f we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users. ]
> > > >
> > > > Lets 100% clarify exactly what we are saying. RPD [ remote desktop protocol ] which could be an Apple, Linux and Windows is communication protocol one machine to another.
> > > > They do not need Windows on the machines connecting, just a RDP client.
> > > > Your programs and data are running / available via the Terminal Server HOST. The machines connecting via RPD is are not 'natively" running your program.
> > > > Each view of a windows desktop [ or managed app ] is really a "view" of the ONE PC [ the server ].
> > > > You might have 5 users, your program is running 5 times on the ONE PC. So it needs to have the resources for this RAM, DISK and CPU
> > > >
> > > > snip[ ... On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them.]
> > > >
> > > > Where clients notice quickly if they move from Windows 7 to 10 and then the "throttling" so it is not just a shared situation. This SMB 1 to 3..
> > > > We had so many hit this wall and could not the system efficiently.
> > > > I could get around SMB1 but the later, they use Port135 and if you shut this down have other issues.
> > > > So when say Windows 10/11 opens says DBF/FPT for one connection, 1 user and another user another machine connects the SMB "throttles" the access.
> > > > But with SQL this does not happen as you are connecting to SQL engine that controls all the connections. The other is via the OS direct and BAM. [ Block Availabiliy Map]
> > > > The locking and unlocking happens there. When you connect to say DBF/FPT it sees host of different machines and users and throttles access speeds.
> > > >
> > > > Taking this all in..... the Terminal Server [ or clones ] owns all the connections, one super client best way to describe it.
> > > > Your customer/ clients / users using RPD to run programs are not throtted because the server is not really dealing with you, but the TS.
> > > >
> > > > For Craig and I am different ways kept these VO apps and DBF operational for clients to stop the massive move to cloud.
> > > > My situation is different as all my competitors which were not cloud have been eliminated.
> > > > The VM strategy has allowed me to keep 100 clients that I would have lost.
> > > > With all these web cloud hack attacks...... a VM is the best security.
> > > > We developed our own 2FA with controls into the VM and users.
> > > >
> > > > But saying all that, it does not win all battles. Have a lot of younger clients, browser or nothing.
> > > > End of 2023 our 100% cloud version will go to market and over time these VM clients will eventually be phased out.
> > > > A PHP and Wordpress front end to same SQL and business logic and reports.
> > > > But this will be their choice. All our "non legacy" development is SQL. No ongoing DBF development.
> > > > We use Postgres or mySQL depending on the market. The learning curve of SQL is well worth the journey.
> > > > Work with a lot of SQL gurus and we can do amazing things easily and a DBF is hard work.
> > > >
> > > > With JSON beiing a major data interchange these days, this is natively supported in SQL.
> > > > Drop it in, query and refactor with a query. That is you do not have to create temp tables or miriad of fields for data then convert backwards and forwards.
> > > > Native means it fully knows how to work with it..
> > > >
> > > > DBF just never designed for this. But a good simple structure will minimal field types.
> > > > DBF say NDLCOM 6 types and SQL like 56 if you want to go that far.
> > > >
> > > > To move clients from DESKTOP ... to say VM we rollout a VM on our own servers hosts [ have many ]
> > > > Allocate an IP we spend day or 5 copying existing over.. they can keep working.
> > > > We setup the new shortcuts for RPD.. some minimal training, user access and levels.
> > > > On the day of full change over we sync any changes and they go live..
> > > > We leave existing system there for 90 days just in case we missed something.
> > > > THen they delete the old system,
> > > > We take over the backups.
> > > >
> > > > Mention if you have an IT company that does this Containers maybe better for space.
> > > > Each VM is a full operating system. We have HOST and might have 20 VMS. So 21 OS on that box.
> > > >
> > > > A container is alike VM without an operating system, it uses the HOSTS OS.
> > > > Never had the time to experiement with it but could save a lot of space.
> > > >
> > > > Phil McGuinness
> > > > ------------
> > > > > THE SOLUTION
> > > > >
> > > > > (I’m talking loud to myself, as though you hinted to it somehow I didn’t get it at first..)
> > > > >
> > > > > Well just tested that if we put all DBF/CDX files in C:\Appdirectory\ in ONE PC and run various instances from various windows users on this machine through RDP , all work fine and fast for all users.
> > > > >
> > > > > On the contrary when accessing DBF/CDX files from a certain shared drive over a network the problem rises and access to files is dramatically slow when another PC uses any of them. The reasons for this are well described on this thread.
> > > > >
> > > > > Thanks all for your thoughts and help!

You havnt specified where the shared folder is located, server or pc, and is it windows or linux etc

If you are using a Windows
Check out these registry settings changes - please do your own research before you change:

[HKLM]\System\CurrentControlSet\Services\LanmanServer\Parameters\EnableOpLocks=dword:00000000
[HKLM]\System\CurrentControlSet\Services\LanmanServer\Parameters\EnableOpLockForceClose=dword:00000001
[HKLM]\System\CurrentControlSet\Services\LanmanServer\Parameters\CachedOpenLimit=dword:00000000
[HKLM]\System\CurrentControlSet\Services\LanmanServer\Parameters\SMB2=dword:00000000
[HKLM]\System\CurrentControlSet\Services\LanmanServer\Parameters\UseOpportunisticLocking=dword:00000000
[HKLM]\System\CurrentControlSet\Services\LanmanServer\Parameters\UtilizeNtCaching=dword:00000000
[HKLM]\System\CurrentControlSet\Services\LanmanServer\Parameters\UseUnlockBehind= dword:00000001
[HKLM]\System\CurrentControlSet\Services\LanmanServer\Parameters\UseLockReadUnlock=dword:00000000
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\OplocksDisabled = dword:00000001