Hello, I’m new to the site… trying to open multiple views of multiple tables. Currently opening up to 24 tables in 1 work area/view. Question, is there a way to open say five tables in one work area, 6 in another, and 5 in yet another… all while maintaining relationships between tables from each work area/view? Trying to open them this way so that each work area/view can be shown on/in a different monitor. Thanks for your help/insite.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Open multiple views of tables into multiple work areas 1
- Thread starter tsibert
- Start date
Dan Freeman
Programmer
First, let's clear up some terminology.
A workarea is a very specific thing. Each workarea can have exactly ONE table opened in it. No more. Ever. What you're describing is multiple Data Sessions. A data sesseion is a collection of workareas.
If you use a form's private data session, each form can have its own set of workareas and opened tables, none of them interfering with the other forms. This can be done with the DataSession class in code, outside the context of a form, but it's a little heavier lift.
A view is a very specific thing, too. (Several, actually. The term has been overloaded over the years.) I first think of SQL views, which are really just cursors begat by a query. There are also old-school .VUE files which shouldn't be used any more. And to confuse things more, the dialog displayed by SET is called "View". It displays all of the opened tables grouped by data session.
I suspect forms with private data sessions will handle what you're after.
A workarea is a very specific thing. Each workarea can have exactly ONE table opened in it. No more. Ever. What you're describing is multiple Data Sessions. A data sesseion is a collection of workareas.
If you use a form's private data session, each form can have its own set of workareas and opened tables, none of them interfering with the other forms. This can be done with the DataSession class in code, outside the context of a form, but it's a little heavier lift.
A view is a very specific thing, too. (Several, actually. The term has been overloaded over the years.) I first think of SQL views, which are really just cursors begat by a query. There are also old-school .VUE files which shouldn't be used any more. And to confuse things more, the dialog displayed by SET is called "View". It displays all of the opened tables grouped by data session.
I suspect forms with private data sessions will handle what you're after.
See also USE ... AGAIN in the help.
-Dave Summers-
![[cheers]](/data/assets/smilies/cheers.gif "[cheers] [cheers]")
Even more Fox stuff at:
-Dave Summers-
Even more Fox stuff at:
Mike Lewis
Programmer
Tsibert,
Welcome to the forum. Dan has given you some good advice about data sessions. I'll just add a couple of points.
As Dan said, each work area can host at most one table. Or, put another way, each table is opened in a separate work area. (It is possible to open a table in multiple work areas at the same time, but I assume that's not what you want to do, so we'll pass over that.)
Now, work areas are numbered from 1 to some high number. When you open a table, you can explicitly select the work area you want to open it in. For example, you could execute these commands:
[tt]SELECT 5
USE Clients[/tt]
That would open the client table in work area 5. In practice, it doesn't make much sense to do that. It would mean that you would have to remember which table was open in which numbered work area, and take great care to ensure you don't try to open another table in the same area.
So, a better solution is to do this:
[tt]USE Clients IN 0[/tt]
The [tt]IN 0[/tt] clause essentially means "whichever is the next available work area". So if you had already opened two tables, the above command would open Clients in Work Area 3. But you wouldn't need to know that. You can just refer to the work area as Clients from that point on. For example:
[tt]USE Products IN 0
USE Orders IN 0
USE Clients IN 0
USE Invoices IN 0
* Four tables are now open
* Do some stuff here with various tables
* Now do something with the Clients table
SELECT Clients
REPLACE ...... && or whatever you want to do
[/tt]
Now, everything I've said above re tables also applies to views. Essentially, you open a view just like you open a table. You open it in its own work area, and the same rules apply. (I'm assuming you are using the term View in the sense of a result set produced by a query, rather than a .VUE file or the View window mentioned by Dan above.)
The above is a slight over-simplification, but if you get the hang of what I have written, you will have made a good start.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Welcome to the forum. Dan has given you some good advice about data sessions. I'll just add a couple of points.
As Dan said, each work area can host at most one table. Or, put another way, each table is opened in a separate work area. (It is possible to open a table in multiple work areas at the same time, but I assume that's not what you want to do, so we'll pass over that.)
Now, work areas are numbered from 1 to some high number. When you open a table, you can explicitly select the work area you want to open it in. For example, you could execute these commands:
[tt]SELECT 5
USE Clients[/tt]
That would open the client table in work area 5. In practice, it doesn't make much sense to do that. It would mean that you would have to remember which table was open in which numbered work area, and take great care to ensure you don't try to open another table in the same area.
So, a better solution is to do this:
[tt]USE Clients IN 0[/tt]
The [tt]IN 0[/tt] clause essentially means "whichever is the next available work area". So if you had already opened two tables, the above command would open Clients in Work Area 3. But you wouldn't need to know that. You can just refer to the work area as Clients from that point on. For example:
[tt]USE Products IN 0
USE Orders IN 0
USE Clients IN 0
USE Invoices IN 0
* Four tables are now open
* Do some stuff here with various tables
* Now do something with the Clients table
SELECT Clients
REPLACE ...... && or whatever you want to do
[/tt]
Now, everything I've said above re tables also applies to views. Essentially, you open a view just like you open a table. You open it in its own work area, and the same rules apply. (I'm assuming you are using the term View in the sense of a result set produced by a query, rather than a .VUE file or the View window mentioned by Dan above.)
The above is a slight over-simplification, but if you get the hang of what I have written, you will have made a good start.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
As the others have said: WELCOME!
While the others have given you some very good advice, perhaps you might want to clarify your needs so that we can better address any issues that we might have missed.
For Example: Are you attempting to do this within a VFP Form and/or do you want to use multiple Form Grids (or Browse windows) ?
Additionally I might suggest that rather than trying to get a single answer on how to open 24 tables at the same time in order to do something, you might begin by simplifying things (open 2 tables as you need, then 3, then 4, etc.) and asking questions as you go.
In that way we can help you get to your final goal in the most effective manner.
Good Luck,
JRB-Bldr
While the others have given you some very good advice, perhaps you might want to clarify your needs so that we can better address any issues that we might have missed.
For Example: Are you attempting to do this within a VFP Form and/or do you want to use multiple Form Grids (or Browse windows) ?
Additionally I might suggest that rather than trying to get a single answer on how to open 24 tables at the same time in order to do something, you might begin by simplifying things (open 2 tables as you need, then 3, then 4, etc.) and asking questions as you go.
In that way we can help you get to your final goal in the most effective manner.
Good Luck,
JRB-Bldr
Olaf Doschke
Programmer
Dan Freeman said:
Dan, T.Silbert may also just describe the result of a view, which may joins multiple tables, in one workarea.
T.Sibert, the way you phrase your question you are very used to legacy FoxPro, which worked via relations etc. SQL can join data of many tables into a single view cursor, which just takes up one workarea, but the joins it makes don't compare to relations all the way. A view or in general an SQL Select takes a snapshot of the data at query time (even though it may take some time). If data changes in underlying tables, the view needs to be requeried to reflect that. In contrast, if you relate two tables via SET RELATION, a change of foreign key adds or removes child records displayed via the relation for the same parent, but doesn't affect a view cursor, which joined the parent with the child records it had during query time.
Besides that, a view based on DBFs will also require a workarea for each source table used in the query andopen them up additional to the one workarea for the result viewcursor. Touching these tables instead of the view again changes data only in them and not in the view cursor or workarea. The opposite can be the case though, if the view is defined updatable (via many meta informations), you can change it and save back changes to the source tables. In that case you can step on your own foot, if you change both view cursor and table(s), as you can cause update conflicts this way. A view may only use it's result viewcursor workarea, if it's a remote view. Remote queries don't "open" remote tables, they defer the task of the query to some driver, eg ODBC or OLEDB and I don't know any database but VFP having the concept of opened tables, just cached parts, eg pages, but no workarea concept.
I hope this clarifies more than it raises new questions, but I fear this is inevitable.
Just take for granted as Dan says, one work area holds one table or (view)cursor, no more, no less.
And no, the "relations" you define in a view via joins are not established in the tables opened for the query. The tables are opened unrelated to each other, in the same manner as any direct SQL SELECT query opens all DBFs you query from, there's nothing special about this, this is just a consequence of VFPs SQL engine, on which views are mainly based, of course, as the main view definition is giving a certain query a name (the main command to create a view is CREATE SQL VIEW name AS <<SQL SELECT query>>). The sql engine internally joins data, the tables it opened additional to creating the result could also be closed. If the view is updatable, this just will cause errors when committing changes, but the view cursor is a result separate from all source data it came from.
Bye, Olaf.
Dan Freeman
Programmer
I suspect use of the word view was accidental, not realizing it has a specific meaning (or several) within the language.
But I'd be happy to be wrong about that.
But I'd be happy to be wrong about that.
Olaf Doschke
Programmer
Dan, you may well be right.
T.Siebert, please expand what you mean with views, as you talk of monitors, you may actually mean windows/forms.
Bye, Olaf.
T.Siebert, please expand what you mean with views, as you talk of monitors, you may actually mean windows/forms.
Bye, Olaf.
- Thread starter
- #10
Thank you all for taking the time required to reply... sorry that I wasn’t clearer. I'm still not sure what the proper names are for what I'm trying to ask but maybe the screen shots will help? the first screen shot is of my left monitor and the second screen shot is of my right monitor and I have one instance of FoxPro open and spanned across both monitors... displaying around 24 different tables that are all in relations to each other in various ways. I think that I'm trying to ask if this could be done so that the one instance of FoxPro doesn’t have to be spanned across the two monitors but instead if there was a way to display the tables in their own view/work area/instance… without the use of forms… as the tables displayed are opened with a FoxPro program.
Thanks again for everyone’s help,
tsibert
Thanks again for everyone’s help,
tsibert
TamarGranor
Programmer
Wow! I think we all missed the boat here because you used words that mean something to VFP developers, but you didn't mean that.
I think most of us would say "Don't do that!" Use forms rather than Browse windows and show only the data you need to see. Surely no one can really work with those 24 tables at once and understand what he's seeing.
I assume that your specific question is how you could put each table into a top-level window with its own presence on the task bar, so you could minimize and restore each separately? The answer to that is that you could only do that by using VFP's forms; you could create a form class that contains a single grid set up to be sized to the full size of the form. That form class could be set as a top-level form. You'd then create an instance of the class for each of these tables.
Again, I don't recommend that. Why don't you tell us about the underlying real-world task you're trying to accomplish.
Tamar
I think most of us would say "Don't do that!" Use forms rather than Browse windows and show only the data you need to see. Surely no one can really work with those 24 tables at once and understand what he's seeing.
I assume that your specific question is how you could put each table into a top-level window with its own presence on the task bar, so you could minimize and restore each separately? The answer to that is that you could only do that by using VFP's forms; you could create a form class that contains a single grid set up to be sized to the full size of the form. That form class could be set as a top-level form. You'd then create an instance of the class for each of these tables.
Again, I don't recommend that. Why don't you tell us about the underlying real-world task you're trying to accomplish.
Tamar
Olaf Doschke
Programmer
Just to expand what Tamar said.
What we see here are a lot of Windows, each showing data of one DBF. Each one can be minimized, maximised, resized and placed where you want. So actually, if you're fine with this kind of interface, which looks very unusable to me, you'd be able to do whatever you want with each little window. Each titlebar has the usual windows controls minimize button, maximise button, close button and you also are able to place a form dragging it at the title bar and resize it at the bottom right corner at the rippled triangle area. Then you can also move and resize the outer window, foxpro itself.
It may also be helpful, if you post a portion (not necessaarily all of) the "application lookup.prg", most probably the code positions the browse windows, so any modification you do is lost next time. But it would be useless to open 24 browse windows without positioning them.
You are far of having an application here, just a bunch of data sheets in the form you use as a developer to have simple low level insight into DBFs. I once did such a setup with relations for a customer administrative user to be able to look into 4 tables, which was already tedious. But 24? No, this will never work out good.
Bye, Olaf.
What we see here are a lot of Windows, each showing data of one DBF. Each one can be minimized, maximised, resized and placed where you want. So actually, if you're fine with this kind of interface, which looks very unusable to me, you'd be able to do whatever you want with each little window. Each titlebar has the usual windows controls minimize button, maximise button, close button and you also are able to place a form dragging it at the title bar and resize it at the bottom right corner at the rippled triangle area. Then you can also move and resize the outer window, foxpro itself.
It may also be helpful, if you post a portion (not necessaarily all of) the "application lookup.prg", most probably the code positions the browse windows, so any modification you do is lost next time. But it would be useless to open 24 browse windows without positioning them.
You are far of having an application here, just a bunch of data sheets in the form you use as a developer to have simple low level insight into DBFs. I once did such a setup with relations for a customer administrative user to be able to look into 4 tables, which was already tedious. But 24? No, this will never work out good.
Bye, Olaf.
Its as I thought in my reply above, the terminology being used was different that we expected.
Since you are new to VFP, I'll recommend that you spend some time learning some of the more basic approaches to using VFP.
One way to do that would be to spend some time viewing the free, on-line VFP tutorials at:
And, I most wholeheartedly agree with the above: Don't Do It That Way.
Instead learn to create a VFP Form (don't use the VF{ wizards) and then put one or more Grid(s) onto the form to display the data.
Additionally, I can't think of why you would need ALL of those tables visible at the same time.
With that in mind, I'd suggest that you review your goal and try to strategize a better development approach.
Good Luck,
JRB-Bldr
Since you are new to VFP, I'll recommend that you spend some time learning some of the more basic approaches to using VFP.
One way to do that would be to spend some time viewing the free, on-line VFP tutorials at:
And, I most wholeheartedly agree with the above: Don't Do It That Way.
Instead learn to create a VFP Form (don't use the VF{ wizards) and then put one or more Grid(s) onto the form to display the data.
Additionally, I can't think of why you would need ALL of those tables visible at the same time.
With that in mind, I'd suggest that you review your goal and try to strategize a better development approach.
Good Luck,
JRB-Bldr
Just to make it easier for you I'll amend the web reference link above to go directly to the VFP tutorial videos:
Good Luck,
JRB-Bldr
Good Luck,
JRB-Bldr
-
1
- #15
Dan Freeman
Programmer
On the other hand, if your ACTUAL goal is splitting the result of a single program so that half appears on one monitor and the other half on the other monitor it seems child's play to put half of that program into a different program. Compile each into its own exe and you're done.
Since that seems such an obvious solution it probably isn't the answer you seek even though it's exactly the situation you've presented here.
I'll join the chorus: 1) DON'T DO THAT, and 2) tell us what you're really after. You'll find us pretty helpful in general. Heck, sometimes you'll get six or more answers just from Olaf.![[thumbsup2]](/data/assets/smilies/thumbsup2.gif "[thumbsup2] [thumbsup2]")
Since that seems such an obvious solution it probably isn't the answer you seek even though it's exactly the situation you've presented here.
I'll join the chorus: 1) DON'T DO THAT, and 2) tell us what you're really after. You'll find us pretty helpful in general. Heck, sometimes you'll get six or more answers just from Olaf.
- Status
Similar threads
- Locked
- Question
- Locked
- Question