<I><FONT COLOR="#663300"></FONT></I>Hi Mike,
If you have a link table then I must assume the actual data relationship is many vendors to many agreements. I am not sure how the real-world concept of an agreement having many vendors works, but that is what is looks like you are doing.
***
Yes, an agreement can have many subcontractors, and the contractors can be involved in many contracts. This is the existing table structure which I am working with, the design has already been made.
***
Even with a many to many relationship, for the sake of a user interface, you would probably do better to choose a one-to-many view of the data.
***
I am trying to achieve this by having the agreement information displayed in bound text boxes, and then have the involved subcontractors, if any, appear listed in a grid on a page frame. There are more children I have to add, to create more grids on other pages, but I am starting with one (for my learning curves sake).
***
<I><FONT COLOR="#663300">When I run the form with the agreement bizobj and txtboxes bound to agreement fields, I can see the records and can scroll through them, using the parent.next().</FONT></I>
How are you using "parent.next" to scroll through the records if the agreement is the parent bizobj?
***
I was afraid a question like this would be asked. The reason is that I do not know why you would ask this question. I want the parent.next() to move the record pointer to the next agreement in the view, so that the associated contractors will appear in the grid(again, if any).
Why would there be a problem using parent.next() with agreement as the parent bizobj?
***
<I><FONT COLOR="#663300">As soon as I even put the child bizobj on the form, I generate errors, such as:
"must be a variable or array"
"object is not found"</FONT></I>
Without knowing which line of code in which method generated these errors, it would be difficult to determine what is wrong. Graeme's suggestion has merit. If you added additional visual controls with the "child" bizobj and did not make sure the bizObj was instantiated first, that would cause numerous difficulties.
***
Thank you Graeme for the suggestion. I have started with a fresh bizobjform, I put both the parent and child bizobj on first, then I put the controls on bizobjform in the order I want them to receive focus
(I have not made the views updateable, until I am comfortable with the what is actually going on, and I have been reading the Fundamentals book, slowly but surely). I have the NoDataOnload set to .F. an after I enter the character string for the vp_agreecid (no period) I get the records as I want them to appear, in the grid. The problem now is that the parent.next() clears the grid, instead of moving to the next agreement, and in the debug output I see "cset.error(10,set,91)" which refers to the line "SET &lcSetCommand &lcClauses" in Set(). Previous moves the pointer back to the original agreement record, but the information on the contractors is no longer the same list?! That is the stage I am at right now.
I made the changes to the properties that you suggested, and am working my way through the code to try and determine where the root of the problem is. Thanks for the responses, at least I am not alone out here. =)
***
<I><FONT COLOR="#663300">alias : v_agreements
ckeyfield : cid
cregistrylabel : ncagreementsbizobj
nchildcount : 1
DE
cdataenvironment : ncagreebizobjenvironment
cregistrylabel : ncagreementsbizobjdeloader</i></font>
The important fields to populate that make parent->child relationships work are:
cKeyfield
cParentBizObj
cParentKeyField
cViewParamName
lPrimaryBizObj</FONT></I>
You don't need to use registry labels. I have a form with a parent, 4 children and two grandchildren that doesn't use registry labels and cascades just fine. cAlias and nChildCount are assigned by Codebook during instantiation.
<I><FONT COLOR="#663300">cviewparamname : vp_agreements.cid</FONT></I>
This probably wouldn't work. The ViewParamName is the name of the variable used in the where clause of the view to filter which records get selected. It should not have a period in it. I suspect it should be vp_cid and that the view is lv_agreements if you followed the Codebook naming conventions.
It's really difficult when you have to put a bunch of things together at once, but I always find I get things up and running more quickly when I step through my code and fix one problem at a time.
HTH
</FONT></I>
Devman
mdevlin (AT) ajdebruin .DO.T com
©2000 Mike Devlin |
