Re: Understanding strategies for establishing relations

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Your question is quite a big one, so probably replies might
grow long-winded...

1) I understand it is better to make connections on a form level, in data
environment, rather then to establish the fixed relations in the database,
right?

The "persistent relationships" in VFPs Database Designer are
technically not required at runtime.
You can use them to illustrate your model visually, and some VFP
wizards can use them if you want, like RI wizard, form wizard etc.
Also, when you use them, at designtime in the Form Designer, Vfp
will suggest a "real" relationship, which often might be the desired one.


2) what sort of key do I put on CMKey in "Models" table?

It's a "foreign key", nothing to do in the table designer, except make
it the same datatype as the "primary key" field of the other table.
And you might want to create an index tag on it (type "regular")
because foreign keys usually need one to perform better ("Rushmore
optimization")


3) what kind of relation to make between tables in form's data
environment?

In the Form Designer's dataenvironment window, drag the primary
key field of the parent table on to its foreign key *index tag of the
child table.

4) what to put in: data environment? Which properties are important on:
- dataenvironment level

Usually nothing more than you'll get while following the steps above.


5) Anything else...?

Yes, you can get rid of that complex type of dataenvironments
as described above by not using xBase "Set Relation" at all.

The alternative would be to (design your tables as you described
and) use (parameterized local) Views for the child aliases.
That way your dataenvironments will be much easier to maintain.

See http://groups.google.com/advanced_group_search for a lot of
NG threads about them, e.g. this one
http://groups.google.com/group/comp.databases.xbase.fox/browse_thread/thread/d5111f7ad6fd4270/2016d82da43f14a9?lnk=st&q=parameterized+views+group%3A*fox*&rnum=11#2016d82da43f14a9


hth
-Stefan



--
|\_/| ------ ProLib - programmers liberty -----------------
(.. ) Our MVPs and MCPs make the Fox run....
- / See us at www.prolib.de or www.AFPages.de
-----------------------------------------------------------

"Bla" <abc@xxxxxxxxxxx> schrieb im Newsbeitrag
news:f3rhud$k64$1@xxxxxxxxxxxxxxxxx
Could someone please explain to me some basic strategies for manipulating
tables with relations?

I understand and accept the concept where every table has unique primary
key field based on integer/autoincremental type. I believe it is a good
way to begin with building relations because if you want to connect two
tables with keys made of one or even more fields, you don't have to sweat
about concatination, various types of fields and so on.

So, let's say we have two tables, "Car producers" ("CP") and "Models" and
we want to put them in relation so that "CP" is parent to "Models". The
goal is to have data from both tables on the same form, so that when you
browse through parent data, the child data shows accordinately. Also, when
you add a child record, it is connected to its parent. (Very basic, I
think. :-) )

So, we have indexes:

"CP"
CMKey (int/autoinc, primary)

"Models"
ModKey (int/autoinc, primary)
CMKey (int, ?)

Every table has it's own primary int/autoinc key automaticaly generated
during creation of each record.

"Models", which is child, must have a field in which the CP key is stored,
so it can be related to its parent.

-------
Now, questions:

1) I understand it is better to make connections on a form level, in data
environment, rather then to establish the fixed relations in the database,
right?

2) what sort of key do I put on CMKey in "Models" table?

3) what kind of relation to make between tables in form's data
environment?

4) what to put in: data environment? Which properties are important on:
- dataenvironment level

- parent table level

- child table level

- relation level

5) Anything else...?


I thank you all in advance.

Mladen


.

Relevant Pages

  • Re: Setlocal equivalent
    ... user logon session. ... The PROCESS environment is a merge of at least USER+SYSTEM (and current ... parent to PROCESS, always transient, and passed as a one way copy from ... Any PROCESS environment change made by a child is not ...
    (microsoft.public.scripting.vbscript)
  • SPS2003 Managed Services search failure
    ... I have Sharepoint Portal 2003 running in a managed services ... environment. ... I set up the parent, turned on managed services, then ... message in the child that it doesn't provide servcies. ...
    (microsoft.public.sharepoint.windowsservices)
  • Some blocking issues in implementing JOS
    ... parent sets the user page fault entrypoint for the child to look like ... But how to copy the _pgfault_upcall of parent environment ...
    (comp.os.misc)
  • Re: what does export do?
    ... >> In Linux a new process inherits the initial set of environment ... Thus anything set in the parent is automatically set ... in the child, but changes made by the child can't affect the ... parent's copy - and reasonable memory management hardware makes ...
    (Fedora)