Goto record key

[G Gabriel]

RE: Goto record key

Tom:
Bear with me, but something is missing.
Judith's goal, as she stated it:
"I have a form where I select a record and I want to set the record of another form the same as the first form... "
So:
She is in a record in form A (which is based on table A) and she wants to set the values in a record in Form B (which is based on table B) to those values in the record from form A.
Now, while you are in form A, my question is: how do you get the recno of the record in form B to which you want the values to be set?
You referred to it as the "child table" but she did not indicate that she is working off a set and if she is, then setting the values of a record in a child table should be a snap and should not require all these DIMing.
So, if these two tables are not linked, then How do you get the recno of the record from table B????? That's is my question.
Gabe

[CALocklin]

RE: Goto record key

I haven't looked at this since my first response so here goes.

First, Judith said nothing about values so I'm not going to discuss values. I don't care what the value of the various fields is now or will be in the future. All I care about is that the record number in form B becomes the same record number as in form A. (Of course, if it's the same records, the values should be the same!)

This is a key point. She did not say she wanted to change the values in form "B", she said "I want to set the record of another form the same as the first form."

This makes a lot of sense if the browse shows only a few key fields but the child record actually has 78 fields that could need to be update. It's much easier to update large records with a form than in one line of a browse.

Next, since her script referred to starting from what appears to be an embedded browse (see the very first line of her script), I made the assumption that she wanted to jump to a child record that was shown in the browse. Perhaps this is the wrong assumption but it's the one I made.

Given that she wants to jump to that specific record - not all records that match a particular value in one of the fields but that specific record number - there are at least three ways it can be done:

1. Get a unique value from the browse (if one is shown) or get a unique value from the child table associated with the browse in the current form "A". (We can't look at form "B" yet because it either isn't open or it may not be on the correct record.) Now open form "B" if necessary and query it to find the record with the unique value - obviously, if the value isn't unique then we will find a range of records and could end up on the wrong one.

In this case, if the table contains 200,000 records, it may take awhile to find the correct record because a query must, by definition, search the whole table. (If it can run a Lightning Query it will run much faster but I won't count on that.)

2. Find a unique value from the child table associated with the browse as in #1 but, this time, make sure it is from a field that has an index associated with it. Now open form "B" if necessary and set the index as required then do a "FormB>.Find("TheUniqueValue>) on it to get to the correct record. At this point, form "B" is on the correct record but it is in the order defined by that index and the developer might want it to be in another sort order in case the user wants to page up or down to other records using a different order. If the order needs to be changed, the index will have to be reset.

3. Get the current record number from the table in the browse, open form "B" if necessary. Jump directly to the desired record number regardless of the index the form is using.

I think option 3 is much easier. We don't care about the index. We don't have to build an operation. It's fast. It's somewhat generic.

Cal Locklin
www.aimsdc.net

[G Gabriel]

RE: Goto record key

Cal:
Thanks for your response. I did not expect this to go on and on as it did!
it seems that you interpreted Judith's goal to mean that she wants the two records to end up having the same recno!
I am not sure what would be gained by assigning a certain recno to a certain record? It does not serve any purpose. Further, I am not sure if you could actually assign a recno to a record! isn't that an internal system function?
That's why the only logical assumption is that she would like to have the values of some of the fields in the first record to transfer to the second, but Maybe instead of trying to figure out what Judith wants, Let Judith shed some more light on specifically what she is trying to accomplish.
I did notice the part about the browse in her first message: But again, for pete's sake, if you have a set, it's almost rudimentary on how to update the fields in the child record, I could think of at least 2 or 3 differnt ways on how to do that with the most basic scripting! Here again is an assumption that these two tables are linked. Maybe Judith could clarify that as well.
Gabe

[whanigsberg]

RE: Goto record key

"it seems that you interpreted Judith's goal to mean that she wants the two records to end up having the same recno! "

Wrong. It's one record; the same record.

Two forms.

Bill

[G Gabriel]

RE: Goto record key

If it is the same record: the field values are the same regradless of how many forms!
Gabe

[Tom Cone Jr]

RE: Goto record key

gabe,

""That's why the only logical assumption is that she would like to have the values of some of the fields in the first record to transfer to the second....""

Not true.

It can be inferred from Judith's original code sequence that her first form is based on a set of tables and contains an embedded browse showing some of the fields in a linked child table. From that it can be assumed that she wants to open a second form to permit the user to edit all of the fields in the "current" child table record. This is what her code would do if it were working and is a commonplace requirement. My initial response to her question was that find by key requires the use of a matching index. Cal's initial point was that you don't have to use a find by key sequence at all, you can use the recno() of the current child table record to jump directly to the desired record.

I'm going to drop out of this thread. It's becoming clear to me that I'm having difficulty communicating, so I'm just going to stop trying.

-- t

[CALocklin]

RE: Goto record key

Exactly the point. "If it is the same record: the field values are the same regradless of how many forms!" I agree completely!

However, if form A has an embedded browse which only displays 3 of the most significant fields in that record (let's say form A is a list of clients and the browse shows company name, contact, and phone number for those clients), please tell me how to edit the other 75 fields for that client (let's say things like address, city, state, fax, CEO name, type of business, etc.) without opening another form? If you decide it's necessary to open another form, how do you edit the correct information unless you are on the same record?

Cal Locklin
www.aimsdc.net

[G Gabriel]

RE: Goto record key

Cal:
Let's get a small dose of Caffeine first which should clear up some of the unnecessary debates and assumptions:
You come to beleive that the two tables are linked in a set, yet in your method you make room for what to do if the child table is not open:
Here comes the caffeine:
If they are in a set: THE CHILD TABLE IS OPEN, PERIOD. WHEN YOU OPEN A SET, YOU OPEN ALL TABLES IN THAT SET. WHEN YOU OPEN A FORM BASED ON A SET, ALL TABLES IN THAT SET ARE OPEN. Further, in that case there will not be Form A and Form B, because Form A, which is based on the set in this case, encompasses the two tables! While you might not have all the fields in the form, yet they are ALL available to you without any straining or DIMing! That's why I said in one of my previous remarks, it seems so preliminary as to how to update the child table. You do not need to fly a spy plane above the skies of the child table to locate a field and a key value and "open" it if not open and point to that record then update it, it's all there under your nose!
Gabe

[G Gabriel]

RE: Goto record key

Tom:
I mis-spoke when I said "the only logical..", I should have said: "the most logical..", please refer to my remark to Cal.
It would be nice if Judith put to rest what she meant!
Thanks
Gabe

[CALocklin]

RE: Goto record key

Yes, the tables are open BUT there is nothing that says all fields of all tables must be on the visible form. So, going back to my other question, how do you propose to enter/edit the other 75 fields if only 3 are visible?

[G Gabriel]

RE: Goto record key

Cal:
I appreciate your patience and deligence.
Assuming that the form is based on the set of 2 tables linked with a one to one link, it's a no brainer:
Here are few ways to do that:
1-You could place the fields you want to update from the child table on the form, if you do not want them visible, hide them, then use a simple xbasic:
fieldA.value= field value from the parent table
no need for hijacking any key values!
2-Let's say you do not want to place the fields on the form for whatever reason and you want to update some fields in the child table with the values of those of the parent table: here again a simple xbasic to use:
table_change.begin()
set your valuse
table_change.end
3-Let's say you want, or for some reason, you like to do things the hard way and let's say you want to find a key value for the child record and bring up this record and update it:
By definition, a set is 2 or more tables linked by a common value of a common field(s)(or expression that evaluates to that value):
If you know the value in the linking field in the parent table then you know the value in the same field in the child table! no need to search for any other key vlaues or recno, use that to locate your ellusive record or if you insist on knowing the recno, use a calculated lookup function. I feel silly even pursuing that when the fields are already there!
Now, let's say the 2 tables are linked in a one to many link and you want to update just one record of the child table and not the others: simple: if the record is visible on the form, use zoom to record and update whatever fields you want to update. If it is not visible, use, as I mentioned in one of my previous remarks, a saved update operation!
You might say, How will this saved opertaion updae just that one record:
when you create a saved operation, you have the option to update all records, marked records, or only records that meet certain criteria: use the criteria you used to choose that record in the first place to update that record! and that's what I meant when I asked Tom if we were re-inventing the wheel by writing an xbasic that basically amounts to runnig a saved update operation!

Gabe

[CALocklin]

RE: Goto record key

Perhaps part of the issue here is the interpretation of the word 'update'. In my opinion, there was never any mention of running any kind of update operation in the original message. The only question was how to go to another form and show the same record as in the browse. I may have mentioned 'updating' but, if so, it was in regard to typing in new information.

Regarding your last comments 1 and 2. I would never update the child table with values from the parent table. This would go against the common rules of normalization for relational databases. (Well, I suppose there's the 'never say never' issue but certainly it would be highly unusual.)

So, since I'm not updating values of one table using values from another, I guess I'll have to type the new info in somewhere by hand. (Maybe the customer sent me a letter with their new address and phone info now that they have moved to a new location.)

One of the common things that is done with A5 to make data entry more reliable is to perform all data entry in forms that are based on only the one table being edited. Can it be done in a form based on a set - yes. However, some people have run into problems when in entering data in sets, especially when entering it in embedded browses, so it has become a common practice to open a separate form for data entry in those cases.

The "FormPointer>.zoom_to_record() command can certainly be used to do this and Action Scripting can be used to do it very easily. Note that the command is "zoom_to record". My routine did essentially the same thing. I wouldn't be surprised to find that the .zoom_to_record() command isn't just a wrapper for code essentially the same as mine.

Cal

[G Gabriel]

RE: Goto record key

Thanks Cal,
I am not suggesting that's what I would do, but if that's what Judith wants, that's what Judith gets and that's why the whole thing seemed odd to me from the beggining!
It was a good hash over anyway!
Later
Gabe

[jarty67]

RE: Goto record key

I have been reading the post you made and I am going to explain whatI doing so that gabriel and eveybody else understands what I am doing...

I have monney transfer records, there can be 10 records with the same sender or same beneficiary... each monney transfer has a unique number, date and time...

What I am doing is this

1. I have a main form search order, where the user selects a transfer number and it shows up on that form..

But if the user does not know the number, but know the sender or beneficiary, he or she is able to select the name of the sender or beneficiary and click on a button next to the sender or beneficiary...

This opens a form search by sender or form search by beneficiary and all the transfers from that sender or beneficiary show up in a browse on that form then the user selects the order he or she wants and click on a button ok...

witch closes the search by sender form or search by beneficiary form and displays the order selected from these forms on the main form 1st form opened..

Hope this clarifies what I am doing

[jarty67]

RE: Goto record key

I used the following from cal:

crec = parentform:tables:child_table_name.recno()
fp = obj( "Action_items" )
IF is_object( fp )
fp.activate()
fp.show()
ELSE
fp = form.view( "Action_items" )
END IF
fp.Recno_goto(crec)


and it is working just like I want it to...

Thanks for all the help

Judith