Still trying to clear cobwebs...

#1

So, I have a 2-table form, where the child table is presented in a table UIO.
I'd like to display only particular records from the child table on the
form. (Clearly, only those related to the parent show, but I'd like to restrict
it further.) But if I based the table UIO on a query, I don't have a key
field to bind the parent to. I considered leaving the parent records off
the form and making a filter field where the client could sort by parent,
so I could do my own filtering as well when the client entered the parent
record, but I really don't want to lose the convenience of navigating the
parent records with the next/prev record buttons. Am I pretty much stuck
with running the query on form.open (or form.init, i imagine) to a temp table,
adding an index to the table, and basing the form's data model on that?
(Would that even work? When in the open process does the form check the
existence of the tables in the data model?) Or is there a better way to
filter records out of a table UIO that I haven't been able to recall yet?

#2

Almost forgot a key detail (sorry about that!) The criteria I'd like to filter
on is not in the child table, but in another related table that is M:1 to
the child. That would be why I'm not using a setRange() or the like.

"George Nassar" <george.DELETEMEnassar (AT) gmail (DOT) com> wrote:

Quote:

So, I have a 2-table form, where the child table is presented in a table
UIO.
I'd like to display only particular records from the child table on the
form. (Clearly, only those related to the parent show, but I'd like to
restrict
it further.) But if I based the table UIO on a query, I don't have a key
field to bind the parent to. I considered leaving the parent records off
the form and making a filter field where the client could sort by parent,
so I could do my own filtering as well when the client entered the parent
record, but I really don't want to lose the convenience of navigating the
parent records with the next/prev record buttons. Am I pretty much stuck
with running the query on form.open (or form.init, i imagine) to a temp
table,
adding an index to the table, and basing the form's data model on that?

(Would that even work? When in the open process does the form check the
existence of the tables in the data model?) Or is there a better way to
filter records out of a table UIO that I haven't been able to recall yet?

#3

I think you are going to have to explain that part better. How can you filter on it
if it isn't in the table? What relation does the criteria have to the table you
want to restrict?

Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits since
1982

#4

Would you perhaps just trust me that it works? :-) That's a lot of typing
you're asking me to do...

I use filter in the informal, "want to leave some records out" sort of way,
not in the "I'm setting up setFilter() criteria" sort of way. The child
data, in the table UIO, has a 1:M to what we'll call a grandchild, set up
on the key field (meaningless, of course). I'm looking to include only those
records in the child table which have at least one grandchild with a particular
field set to True. So filtered on Max(BoolField) in the grandchild, I guess
you could say. Not hard to pull those records with a query, but then I have
to programatically create indices on the answer table to use it in the form.

Does this make more sense?

Dennis Santoro <RDAPres (AT) NoRDASpamWorldWide (DOT) com> wrote:

Quote:

I think you are going to have to explain that part better. How can you filter
on it
if it isn't in the table? What relation does the criteria have to the table
you
want to restrict?

Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits
since
1982

#5

I've handled this with a structure like this:

MASTER ->> RESULT* -> DETAIL

....where RESULT is a keyed table in PRIV into which the primary key
values from the DETAIL table are inserted (by query or code) for those
DETAIL records you wish to view. RESULT also needs the MASTER's key:

MASTER.ID ->> RESULT.MasterID
RESULT.DetailID -> DETAIL.ID

RESULT is keyed off both the MasterID and DetailID fields.

Hope that makes sense.

Liz

George Nassar wrote:

Quote:

So, I have a 2-table form, where the child table is presented in a table UIO.
I'd like to display only particular records from the child table on the
form. (Clearly, only those related to the parent show, but I'd like to restrict
it further.) But if I based the table UIO on a query, I don't have a key
field to bind the parent to. I considered leaving the parent records off
the form and making a filter field where the client could sort by parent,
so I could do my own filtering as well when the client entered the parent
record, but I really don't want to lose the convenience of navigating the
parent records with the next/prev record buttons. Am I pretty much stuck
with running the query on form.open (or form.init, i imagine) to a temp table,
adding an index to the table, and basing the form's data model on that?
(Would that even work? When in the open process does the form check the
existence of the tables in the data model?) Or is there a better way to
filter records out of a table UIO that I haven't been able to recall yet?

#6

Liz McGuire <liz (AT) paradoxcommunity (DOT) com> wrote:

Quote:

I've handled this with a structure like this:

MASTER ->> RESULT* -> DETAIL

...where RESULT is a keyed table in PRIV into which the primary key
values from the DETAIL table are inserted (by query or code) for those
DETAIL records you wish to view. RESULT also needs the MASTER's key:

MASTER.ID ->> RESULT.MasterID
RESULT.DetailID -> DETAIL.ID

RESULT is keyed off both the MasterID and DetailID fields.

Hope that makes sense.

Liz

Sure does. That's pretty much what I expected to have to do. I imagine
RESULT would just be filled from code in form.init. Obviously the RESULT
table has to be around to make the form's data model, but does it actually
have to exist before form.init runs? It'd be nice for low-clutter's sake
if I could create RESULT on the fly from form.init instead of leaving it
there and filling it -- which, of course, is only possible if the data model
is checked after init, before open. Any idea?

#7

IMO, you'd be better to create it and leave it in PRIV, then empty it
before the init process. However, in testing, you may find it works
without it already existing, but I kinda think the tables in the DB
need to be there before init (may depend on the Paradox version).

Liz

George Nassar wrote:

Quote:

Sure does. That's pretty much what I expected to have to do. I imagine
RESULT would just be filled from code in form.init. Obviously the RESULT
table has to be around to make the form's data model, but does it actually
have to exist before form.init runs? It'd be nice for low-clutter's sake
if I could create RESULT on the fly from form.init instead of leaving it
there and filling it -- which, of course, is only possible if the data model
is checked after init, before open. Any idea?

#8

Sort of makes sense if I understand what you wrote. Try this.

Have a template table that is 2 long ints, both indexed. Have this table empty in
your main data space. Have the form init copy it to PRIV as __Link.db or something.

Have this in your data model

Parent.db -->>__Link.db-->child.db

Now, to fill it, scan the grandchild table. For each instance you find that meets
your condition, locate the corresponding Child record. Grab the key and foreign
key, insert a record in __Link.db and place the Key and FK (doesn't matter which,
just be consistent. Now this link table provides the limited set while letting you
show and navigate as if you had the child linked to the parent.

Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits since
1982

#9

Guess I should have read yours before I bothered with mine. Pretty much the same
solution with only a couple of different details.

Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits since 1982