Set structures: Dr Jeckel Mr Hyde

[G Gabriel]

This probably is a futile pursuit, but before writing it off, I thought I put it out there and see if there are any intuitive or ingenious ideas that might come my way.
Suppose you have a one-to-many set.
1-The parent is a table of tasks (Table has the fields: Task & location among others).
2-The child records shows the employees to perform each task.
In a form based on this set, when you scroll though the parent records, you will see one task at a time and in an embedded browse the employees assigned to that task.
Suppose you want to group these tasks by location (still in the form display):
1-You want a browse showing unique locations and
2-a second browse showing the tasks for that location
3-In addition to the embedded browse showing the employees.
Question: How could you accomplish that with the same set structure you have and without adding new tables or aliases?
To my knowledge, to accomplish that you would have to either:
a-Create a new table (locations) and include it in the set as the grand-parent and make the parent a child (to show the tasks for that location), then the employees as a grand-child or
b-Use the parent as an alias in the same structure mentioned previously
I am looking for something other than these two options. Any suggestions??
I doubt seriously that this could be accomplished unless alpha introduces a new concept, let's call it "Clones" as opposed to aliases (actually the nomenclature should be reversed). The reason I doubt that it could be accomplished in the current environment is because you will be asking the same parent table to be Dr Jeckel and Mr. Hyde at the same time, something you cannot do not even in the movies !!
But I am hoping that someone out there could show by some means or trickery how to accomplish that. You could do it in a report mind you (I will pass on composite tables).
Thanks
Gabe

[csda1]

RE: Set structures: Dr Jeckel Mr Hyde

Hi Gabe,

If I understand your question,

Take the table and sort it by location/task. Actually this doesn't matter, but is probably a good index to have.

Link it to itself (as a read-only child) by task only to the same table by the location linking field. Then take the employee table and link it as a grandchild based upon employee #)

Regards,

Ira

[G Gabriel]

RE: Set structures: Dr Jeckel Mr Hyde

Ira:
""Link it to itself (as a read-only child) by task only to the same table by the location linking field.""
That would be an alias. I am trying to avoid that.
Gabe

[csda1]

RE: Set structures: Dr Jeckel Mr Hyde

Gabe,

Why are you trying to avoid the alias? Is there an implied issue? Perhaps if you could give the reasons for you looking for an alternative, perhaps that might illuminate what your true goal is.

Regards,

Ira

[Jim Chapman]

RE: Set structures: Dr Jeckel Mr Hyde

Hello Gabe,

If you don't want to link the tables in as alias's, the only other approach I can think of is to put a couple of list boxes on the form bound to variables. Then via xbasic populate the list boxes with the table values you want. You could use the onFetch event to repopulate the lists as you moved through the records. I don't think you'd have as many choices in terms of appearance, but I think the list box would have the same events as a field to allow you fine grained xbasic control.

Good luck,
Jim

[G Gabriel]

RE: Set structures: Dr Jeckel Mr Hyde

Ira:
""Why are you trying to avoid the alias? ""
I was hoping no one will ask that question !! that will be a new thread altogether: In summary:
1-From experience, when you get to a "critical" number of tables in a set, alpha starts to have hiccups and things go haywire
2-The set I have involves more tables than mentioned in the example given and as such things will get more complicated
3-In a report: if you try to use sub-reports to extract records from multiple one-to-many links in a set, it won't work. It's supposed to, but it does not.
I do not wish to go into too many details into these subjects since as I said the context of this thread will be totally altered.
Gabe

[G Gabriel]

RE: Set structures: Dr Jeckel Mr Hyde

Jim:
Thanks, that's a good idea except the list will be rather long since there are dozens of locations.
I thought along the lines of a list or an array, but never really gave it any further thoughts hoping that there might be a better "trick".
Gabe

[Jim Chapman]

RE: Set structures: Dr Jeckel Mr Hyde

Hello Gabe,

"" the list will be rather long since there are dozens of locations""

Dozens are no problem, tens of thousands........ might make a noticable lag.

Jim

[G Gabriel]

RE: Set structures: Dr Jeckel Mr Hyde

Thanks Jim, I will give that a try and see how it goes.
Gabe

[Finian Lennon]

RE: Set structures: Dr Jeckel Mr Hyde

This is one of those perfect examples of where an Xdialog shines because it can be created without the constraints of set design and linkages. And this is definitely NOT meant to reopen a debate about forms v xdialogs.

You could have an Xdialog with a display of the parent with buttons to change the display and order of the parent records. This would give you the groupings you want i.e. by task or location.

The child displays could react as the parent record changes focus. I haven't done exactly what you describe, but have done enough Xdialogs to display "child" data in different ways depending on what is showing in the parent that I think it would be fairly straightforward. It wouldn't need any extra tables, just different views responding to different queries. Since it's likely you already have the needed indexes on the child table(s) the performance would be indistiguishable from a regular form.

This is one case where I think function conquers form (!) and to achieve that I'm very happy to accept any coloring or other cosmetic limitations that the Xdialog imposes on me. I definitely find playing with Xdialog colors to be tedious.

Finian Lennon

[G Gabriel]

RE: Set structures: Dr Jeckel Mr Hyde

Finian:
Thanks for he replay. We certainly do not want to revisit the debate about forms/xdlg, but your suggestion in the end will have two layouts open: the xdlg and the form !! That is not what I am looking for, else I could have two forms open (instead of a form and an xdlg) and do exactly what you described.

I am trying to accomplish all in one form (or if you prefer an xdlg whichever flavor you like).

I do not need an xdlg to toggle the index: I could do that by adding a simple button event on a form instead of creating xdlg with buttons !! In fact, I might not even need any buttons: you could conceivably create an OnInIt even of the child table to change the index. But that is short of what I am looking for: I want to see the full picture all at the same time: unique locations, tasks for that location and employees for each task.

Alpha will do exactly what I am trying to do in a report, but not in a form much less on an xdlg. I am assuming that is because in a report, alpha creates composite tables and hence, retrieve values grouped whichever way and as needed off those composite tables.

The issue does not have anything to do with forms' (or xdlg) limitations, it has to do with the fact that the grouping based on a certain field in a table (i.e. showing unique values of that field) negates the other objective: showing all records (in order to see all tasks) of the same table. It's an issue of indexing and display.
In a form (or a browse for that matter), you cannot display the SAME table with two different indexes at the SAME time, hence my analogy to Dr Jeckel Mr. Hyde! and hence my suggestion for clones/aliases if any of that makes any sense.
Gabe

[csda1]

RE: Set structures: Dr Jeckel Mr Hyde

Hi Gabe,

"In a form (or a browse for that matter), you cannot display the SAME table with two different indexes at the SAME time, hence my analogy to Dr Jeckel Mr. Hyde! and hence my suggestion for clones/aliases if any of that makes any sense."

Actually you can. Create a dummy parent table that connects to all records of the task table set up twice as 2 children, one sorted by location, the other sorted by task.

Regards,

Ira

[G Gabriel]

RE: Set structures: Dr Jeckel Mr Hyde

Finian:
I hate to say it and I will say no more on that subject, but while you were trying to boast xdlg, you exposed one of it's major disadvantages:
You can not display an xdlg with a parent record and all the associated child ones in the same xdlg!!
My last word on that subject:
If xdlgs are fundamentally better than forms, then for the love of God pour all your programing force on it (speaking to alpha's staff), or vice versa, as, in my opinion, it is better to have ONE tool with more functionality than two tools with the same functionality. It's a matter of "Quality" not "Quantity". I will say no more on this devisive subject. This thread, by no means, was meant to re-open that subject and I hope it does not.
Gabe

[G Gabriel]

RE: Set structures: Dr Jeckel Mr Hyde

Ira:
Yes, but you have to have that dummy table or by some means or another a second instance of the same table (hence I described alias as a misnomer since you will have two instances of the same table, should more properly be called clones not aliases). This is not an alpha issue, I believe other databases refer to them as aliases as well and the semantics are of secondary importance in the context of this thread.
Gabe

[Finian Lennon]

RE: Set structures: Dr Jeckel Mr Hyde

On what do you base this statement?

""you can not display an xdlg with a parent record and all the associated child ones in the same xdlg!!""

The concept of parent and child has no meaning in xdialog.

Table A has an ID field, a State field and a telephone field.

Table B has an ID field corresponding to the ID as well as fields containing state and telephone numbers

If I place all (or a sub-group of) of records from table A in a list box on an xdialog. I can place 3 other list boxes based on table B on the SAME xdialog.

Each time a record in the first list box based on table A gets focus:

List Box 1 Table B shows ALL records with the corresponding ID
List Box 2 Table B shows ALL records from the same state as the current record in table A
List Box 3 Table B shows ALL telephone numbers in the area code corresponding to the area code of the current record of table A.

How is this not showing all associated records? In fact you can create and show a theoretically unlimited number of different associations.

I wouldn't even begin to attempt to discuss your other views since they don't allow for reasoned debate of any kind, but your comment above seems to be a simple misstatement of fact.

Finian