Is this as expected?? Do I miss something??
Phil - and all!
Thanks a lot for the feedback. What do you mean "move to VM??"
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 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!
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 45:05:20 |
| Calls: | 10,392 |
| Files: | 14,066 |
| Messages: | 6,417,260 |