Need help with a concept for sharing data between VFP apps

[cfsjohn]

I have a VFP app. It runs on cloud servers (not sure that matters for this discussion).
I have many customers. My customers for this discussion are companies.
Sometimes one of my customers will run multiple instances of my app. Each instance is totally separate, having no knowlege of the other instance.
When my customers are running multiple instances of my app, there is a need to share some of the data maintained by my app across those multiple instances of my app.

Here is the normal folder structure for my app:
Myapp home directory
Under Myapp home directory is the usual DATA folder

When a customer is running multiple instances of my app, simply for organizational purposes I setup the folder structure like this:
Company1 folder
MyappInstance1 home directory
Under MyappInstance1 home directory is the usual DATA folder
MyappInstance2 home directory
Under MyappInstance2 home directory is the usual DATA folder

To be clear, there is a shortcut on the desktop to run MyappInstance1.exe from Company1\MyappInstance1
and a shortcut on the desktop to run MyappInstance2.exe from Company1\MyappInstance2

I have a database, let's call it Myapp.dbc
Inside the dbc are a lot of tables. Let's say we have TableA, TableB and TableC.
There is an instance of Myapp.dbc in both the Company1\MyappInstance1\Data folder and there is an instance of Myapp.dbc in the Company1\MyappInstance2\Data folder.

Now, lets say TableC contains data that I would like to share between MyappInstance1 and MyappInstance2.
I would create another dbc named MyappShared.dbc
I take TableC out of Myapp.dbc and move it to become a table in MyappShared.dbc
The location for MyappShared.dbc would be relative to both Myappinstance1's home and MyappInstance2's home using ..\

As long as I use the same folder structure for all companies running my app, even when they only need one instance of my app, meaning there would always be a CompanyX parent folder, this should work. Right?

Thanks,
John

 

[GTGeek88]

This seems strange to me. Why would a customer, whether running multiple instances of the app or not, want to access data that was not a single copy of their data? There's no reason that one instance or two instances or more can't access the same database. As for running multiple instances, there is code that will prevent that, if desired. And a user should be able to open multiple instances of any form in the system, which might give them what they want. In other words, in a single instance of your app, they should be able to open one, two, three, or more instances of the customer maintenance form or the invoices form or the sales order form. Talking to one customer and another calls? Don't be bothered with having to save or cancel your changes. Just open another instance of the customer maintenance form for the second customer. Make the changes there, save, close, and then just click on the first instance of the form and continue with the first customer. VFP handles that within a single instance of your program no problem, if properly coded.

 

[cfsjohn]

This seems strange to me. Why would a customer, whether running multiple instances of the app or not, want to access data that was not a single copy of their data? There's no reason that one instance or two instances or more can't access the same database. As for running multiple instances, there is code that will prevent that, if desired. And a user should be able to open multiple instances of any form in the system, which might give them what they want. In other words, in a single instance of your app, they should be able to open one, two, three, or more instances of the customer maintenance form or the invoices form or the sales order form. Talking to one customer and another calls? Don't be bothered with having to save or cancel your changes. Just open another instance of the customer maintenance form for the second customer. Make the changes there, save, close, and then just click on the first instance of the form and continue with the first customer. VFP handles that within a single instance of your program no problem, if properly coded.

GTGeek88,
You are using the wrong definition of the word "instance" or I chose to use the wrong word.

When I said instance, I mean 2 completely separate apps. For example, you are a CPA. You do the books for Company1 and you do the books for Company2. You use quickbooks desktop app to run your business. You have 2 completely independant installations of Quickbooks on your computer. When you are working on Company1's books you run Company1's instance of Quickbooks. When you are working on Company2's books, you run Company2's instance of Quickbooks.

Sorry about the confusion,
John

 

[igorsandler]

This seems strange to me. Why would a customer, whether running multiple instances of the app or not, want to access data that was not a single copy of their data? There's no reason that one instance or two instances or more can't access the same database. As for running multiple instances, there is code that will prevent that, if desired. And a user should be able to open multiple instances of any form in the system, which might give them what they want. In other words, in a single instance of your app, they should be able to open one, two, three, or more instances of the customer maintenance form or the invoices form or the sales order form. Talking to one customer and another calls? Don't be bothered with having to save or cancel your changes. Just open another instance of the customer maintenance form for the second customer. Make the changes there, save, close, and then just click on the first instance of the form and continue with the first customer. VFP handles that within a single instance of your program no problem, if properly coded.

Completely agree. We have the same thing when the same user can open the same form from multiple sessions of the same data, that is not a problem at all. The only thing we do is locking up the processes that create transactions: billing update, payment update etc. But maintenance form can be open using multiple instances by the same or multiple users, not a problem

 

[ggreen61]

I have an accounting program that has a single instance of the database (DBC) located on a NAS. Every table has a key field for the Company Id (field name companyid) and has an index built on this field in addition to the other keys for the table. When a user logs into the program, they have to select what company they want to access (the company is checked that they also have access to the selected company Id). This log-in sets a custom property on _VFP.CompanyId to the company Id value. This property value is then used in every SQL SELECT command to select that company's data records; i.e.

SELECT field1, field2, ... FROM table1 WHERE companyid = _VFP.CompanyId AND ... INTO CURSOR c_table1

The _VFP.CompanyId is also used in every table INSERT or UPDATE command.

This allows a single database to contain all the data for each company and keep it separate. No need to have separate DBC and tables...

 

[Chris Miller]

Sharing data means having it in a single DBC, so that's absolutely okay:

I would create another dbc named MyappShared.dbc
I take TableC out of Myapp.dbc and move it to become a table in MyappShared.dbc
The location for MyappShared.dbc would be relative to both Myappinstance1's home and MyappInstance2's home using ..\

In a LAN situation you'd share data within a network share, your cloud computing situation (and yes, that plays a role) means a local directory can hold the shared data as multiple users run their apps on he same cloud computer and that's scalable by cloud computing, no matter how Amazon, Microsoft, Google etc. do that by virtual hardware, not your concern.

It also doesn't matter if the data is shared in two instances of the same application or in two instances of different applications. But when you want to share data between different applications, not only different users, then what I usually did is still defining a main DBC for each of the different applications and sharing data would mean other applications also open/use DBCs of other applications. So in principlpe any application could use all tables of all applications, too. Obviously, to avoid mishaps, you could do that through a shared app that does the data access and could handle access permissions, log usage, etc.

And if you don't want to establish a data acess app that has to be used by your applications, when they want to access a foreign DBC of your whole data, then a simple means to that would be defining a views DBC for access to all foreign DBC tables you want to query, updatable, if necessary. So any app would have its own main DBC, you'd not define a shared DBC for shared data, but define each applications view DBC for access to foreign DBCs. Local views that is, for accessing dbfs, remote views only become necessary, when you move to MSSQL or other DBMS.

That way, you only establish and extend a view DBC or a data access app and every DBC of the applications stays the same, you don't move tables around and break code that still expects them in their original DBC and you can start immediately with sharing a dbf without needing such moves and code adaptations in the applications that all need to change their dbf access from their own main DBC to a shared DBC.

Well, one core requirement for that idea of keeping dbfs where they are and only establishing views or a data access app, of course, depends on DBCs being shared in principle available to all applications. So indeed you may want to aim for a situation where you have the main directory structure /data/ for all DBCs and a parallel directory /apps/ for all apps, which means each app can see any DBC relative to their exe location say /app/app1/app1.exe as ../../data/app1data/app1.dbc or other DBCs as ../../data/app2data/app2.dbc, so both the own and other dbcs are available. You're still in full control which applications access which dbcs at all and which of the tables, so just because you technically need to share all data for that, your apps still only share data necessary to share.

But once that's established it means it's simply defining a further view to access yet another foreign table or even just adding the code for that in whatever exe, no location of dbfs has to move, no code acessing any dbf that becomes shared data needs to change, ever.