1 Form containing more than 1 set

[compee]

Hello,

The question that follows is a development strategy question, not a specific problem. In ACCESS we commonly develop complex forms by using multiple queries in one form or embedding many levels of subforms in the same form.

With Alpha 5 one can only use one set per form. There must be an additional strategy that allows more complex content to be added to one form such that the form works with more data than one set.

Can one use a query based upon data other than the set imbedded in the form to create more complex data processing or add more data to the form?

Has anyone encountered this limitation and found another method to solve this problem?

Thank you for you assistance,
Compee

[Garry Flanigan]

Re: 1 Form containing more than 1 set

Are you thinking of data from different tables that is not related in any way? Can you give an example of how you used this in Access?

[rmcgaffic]

Re: 1 Form containing more than 1 set

Gary, how about this for example:

Display the names of all my customers who live in Pittsburgh, PA
AND
Display the names of all my vendors who live in Pittsburgh, PA
AND
Display the names of all my employees who live in Pittsburgh, PA

using tables MyCustomers.dbf, MyVendors.dbf, MyEmployees.dbf with the following structures

CustomerId
CustomerName
CustomerCity

VendorId
VendorName
VendorCity

EmployeeId
EmployeeName
EmployeeCity.

The results of each query should be displayed on a form with three browses: one for customers, one for vendors, one for employees.

How would you define the set to accomplish this?

There is no need for a set using Microsoft Access, but a workaround is required with Alpha Five.

As it turns out this capability is fairly important, if you have any hope of including a "dashboard" in your application -- with the need to display summarized information from many different tables.

Bob McGaffic
Pittsburgh, PA

[Garry Flanigan]

Re: 1 Form containing more than 1 set

Bob,
In your example all data are related.
If I wanted to have three browses (one for each table), I would create another table "MyCity" with a field "city" and then create a set based on it (MyCity) with the three tables you mention as child tables.
Moving from record to record in MyCity will then show the related child records.
The form would have a field Mycity->City and three browses, one for each table you mention.
The links are:
- MyCity->City to MyCustomers->CustomerCity
- MyCity->City to MyVendors->VendorCity
- MyCity->City to MyEmployees->EmployeeCity

[MikeC]

Re: 1 Form containing more than 1 set

Bob,

a workaround is required

hmmmm....well, lets see...I do not see the alternatives as a work around.....but I also do not see how it could be any easier with Access.

You can use Alpha forms which are based on tables and sets which, for the most part, enables much faster development especially for those who do not wish to learn a programming language.

OR learn a little bit of xdialog(or none at all using the xdialog genies) to create the unbound "forms" or "browses" that seem to be what is wanted. Xdialogs can even be embedded on forms now....I just used it in fact just for the purpose of having a checkbox list that is from an unrelated table.....see attached....the one with several checkbox "browses" is completely xdialog...the other has the embedded checkbox listbox xdialog on a form--lower right hand part.

Bob I know you don't like just pictures of things created, but each project is unique (or confidential)--they are sort of "proof of concept" really is all---but much of what I have produced is based upon genie code (with sometimes slight, sometimes major modifications).

So how is it harder to do this than with Access? I am really curious as you have mentioned this quite often---does access have genies that basically write the code for you to create these unbound forms/browses? And, if so, are the Access genies easier somehow to use than the Alpha genies?






But getting back to the thread topic.

Compee,
Once what you want is explained and is understood, then a method can most likely be suggested....once you try to accomplish it and run into problems then ask here regarding them.

[compee]

Re: 1 Form containing more than 1 set

Thank you MikeC. That was exactly the information I needed. I now have an understanding of the basic strategy to pursue.

Compee

[rmcgaffic]

Re: 1 Form containing more than 1 set

Gary,

Creating a new table called MyCity is exactly the sort of workaround I am trying to avoid.

Having to create and populating tables just to handle simple browses or queries is generally not a good strategy. Access does not require such a workaround.

What if my browses looked like this: On a single Alpha five form
display three browses as follows:

All my vendors located in Pittsburgh, PA
All my customers located in Philadelphia, PA
All by employees located in Erie, PA

Sorry, my orginial example was unrealistically simple.

I've attached something that I whipped up in three minutes using MS Access shown in the screen print below.

Bob McGaffic
Pittsburgh, PA

[MikeC]

Re: 1 Form containing more than 1 set

xdialogs populated via each table--believe it will do this from the genie using the option to populate from a table, but using straight-forward, basic xBasic it would be similar to:

table.external_record_content_get("Vendor Table", "Vendor Name", "", "City=\"Pittsburgh\"")
table.external_record_content_get("Customer Table", "Customer Name", "",  "City=\"Philadelphia\"")
table.external_record_content_get("Employee Table", "Employee Name", "",  "City=\"Erie\"")

Substituting in the appropriate table and field names. Each xdialog would then have the records corresponding to each "unbound" table wanted.

And why not use sets as you seem determined to have everyone try and seem also to feel that not being able to use them is a shortfall of some kind??.....well, this is not Access. Tables and sets in Alpha are not to be used for such things (normally not but can be with "work-arounds"--there's that nasty word again...but somehow I love how almost anything wanted can be done in Alpha even though it may not have been initially designed to do it!!).....xdialogs can and are used to add data from unrelated tables without utilizing work-arounds.

[Garry Flanigan]

Re: 1 Form containing more than 1 set

Bob,

Creating a new table called MyCity is exactly the sort of workaround I am trying to avoid.

How confusing will it be to the user to ever figure out how to initiate a search if you go some other way?

Isn't the idea to make an application easy to use? This means the developer may need to do some more work.

Is your revised example a real situation?
If so, what is so hard about opening three forms? How do you set the filters for each of the three browses to get a different city in Access?

[JohnZaleski]

Re: 1 Form containing more than 1 set

Another possibility is the ablity to embed the grid component in an xdialog( all done via a genie).
The grid is an elegant way to display and allow user interaction with data fields.

[rmcgaffic]

Re: 1 Form containing more than 1 set

Mike,

One of the challenges of business information is getting the "Big Picture". Many companies have developed dashboards which allow them to see on one screen information from multiple sources: such as top ten customers, change in employee absenteeism, vendors with the greatest incidence of late deliveries.

So using separate forms for this information is not desirable.

In thirty seconds I was able to limit my list of employees to only those whose first name was "Robert" in Microsoft Access.

Yes, I understand that A5 is not Access, but I am very much interested in doing things as simply and cleanly as possible.

Just to make sure I understand what you are proposing:

1. Place a SuperControl on the desktop form
2. From the popup dialog box, select Embedded XDialog
3. The embedded dialog box pops up, and "Place dialog content here..." is indicated.

Perhaps, I'm just dense, but is this all the genie does, or how can I get it to generate the code for me?

You noted

believe it will do this from the genie 
using the option to populate from a table,

I must be missing something because all that I see is what is in the second screenprint. Where is the option to populate from a table that you mentioned?

Or is the idea to use action scripting to generate the code and them cut and paste it back in to this dialog box.

Wouldn't a really neat design have been to allow you to jump to action scripting, convert the action script to XBasic, and then drop the XBasic code into the genie dialog.

Again, I'm looking for the easiest way of doing this. The beauty of what I demonstrated with Access was that I did not write a single line of code.

Bob McGaffic
Pittsburgh, PA

[Davidk]

Re: 1 Form containing more than 1 set

MikeC,

This type of "problem" is really easy to handle in Access since "browses" on Access forms are not locked into the table or set the form is based on.

An Access sub-form (or browse) can be based on any table in the database. In order to get it to sync to the main form you do need a common piece of data between the main form and the sub-form. The sub-form is usually based on a query - again any table in the database - and in that query you can enter "criteria" for selecting specific records. That criteria usually refers back to data on the main form - thus creating the link and filtering the sub-form.

I find in Alpha that you have to be really careful when designing - not a bad thing - but...

Just recently I wanted to show daily Member Scans on a Membership form. I'd not allowed for that in the design. It wasn't a big deal - I have to add the Scans table to the set.

In Access I would not have had to change the base set to easily get that information on the form.

Thought I'd lay it out since you asked.

David

[Garry Flanigan]

Re: 1 Form containing more than 1 set

David,

In order to get it to sync to the main form you do need a common piece of data between the main form and the sub-form.

This is what happens in Alpha when you create a set.

[Davidk]

Re: 1 Form containing more than 1 set

Yes... and it's not a really big deal... but the table must be part of the set. In Access it is not required. You could have twenty sub-forms in an Access form coming from 20 tables but those tables are not part of the main form's query.

It's just how it's done differently... that's all.

[MikeC]

Re: 1 Form containing more than 1 set

Thanks David,
I think I understand a bit better how Access works differently.....and the ease of it would be handy...and even wanted....if the trade-off that would happen did not--that is with Alpha's sets, the data is Bound and that can aid a developer many times. And the fact that with xdialog (and the ability to use it on a form) you can have unrelated (unbound) data brings Alpha's ability to more than overshadow Access's abilities. To do what Access can but also more! A few extra steps to have a more powerful RAD tool....a no brainer for me....but then I was never one to have to have it easy, just a need to have it do what I want, when I want it.

Bob,
You are correct in that Alpha could for sure make it easier to have the code inserted in the embedded xdialog. As it is you have to first create your xdialog (easy with genie)....then actually have to take it apart a bit in order to insert the correct parts of it into the embedded xdialog code (not possible with genie). The last part should be made easier....but is not that difficult when following the instructions on the embedded xdialog.

Look, last fall was the first time I had EVER used xdialog (had to for certain projects). Using the genie....then reusing what I, or others, had created to expand upon was (is) not that difficult. Let the genie guide you, follow the instructions. After a few times I bet you will be able to create these embedded xdialogs very fast and the extra steps will not even be considered a burden to do.

People here (even developers) have many times said that it is an entirely different language than xbasic....and that it was difficult to learn. I have found it to be mostly straight-forward as was xbasic, but for sure is much "pickier" than xbasic....but at least when you do something wrong with xdialog you will know right away that it is wrong!!---it simply blows up!! :D I found the most difficult parts are the lack of formatting available (now that is an issue we have for sure covered in the past and you know I agree with you on that one!!!).

:) Wow Bob, you certainly do get me going on and on about things!! Guess you make me want to spend my 2 cents more than I do with other issues I run across!
Nice to have the pros and cons of various matter discussed though I feel.

Take care and hope I didn't ruffle/rumple your feathers too much here!