Subject Re: Form to Form From Lee Grant <camilee@nospam.comcast.net> Date Sun, 11 Jun 2023 18:10:48 -0400 Newsgroups dbase.getting-started Peter, I understand the confusion you must have. When I developed my little program, it was confusing for me also, and even Mervyn didn't understand why I was using 2 query's of the same dataset either, but assured me it was okay as long as I kept track of how they were being used and synced, hence the two different names so I wouldn't confuse the purpose each one was going to represent. Whoever advised you NOT to use the same query on the child form as that opened in the parent form may have just been trying to save you from what they perceived as a confusing situation, but as long as you keep the parent's query from being changed by making the child form modal, that shouldn't be able to happen. In my programs case, I specifically wanted to change the dataset (via the triplistdata query) so that the (triplistvisual) didn't change while I was manipulating the data behind the scenes, and then I could update the visual query when the behind the scenes data query was done. That's because the visual representation didn't have the same fields being shown as the full data that was being entered, and if I created a new row, I didn't want all the flickering going on in the visual.  So what I did, was create a form that came up modal, took the data from the parent query that was available in the visual form (in this case, a number that is unique) and was able to test for it's existence or not and handle the addition or refusal of a new row based on that...and if it wasn't new, it would put that unique number in the new row, and allow me to put the additional new information in it, and then when saving, it would trigger a requery of the visual query and allow it to show the new entry and the fields that it needed to show. As long as you keep good track of your plumbing, the only time you can't do something, is when dBASE refuses to allow you, or at least throws an error that you're doing something wrong and need to fix it. Neither is wrong, but had different needs. Like you, I didn't realize I had to create those specific connections between the two forms, and the datalink from the fields to the query's fields so they could communicate. I'm going to try and see if I can't make it work the way you seem to have it currently designed, since Mervyn's having his own issues to deal with to get back to you timely, but I'm slow and he's the expert...so no promises. :) Lee On 6/11/2023 10:46 AM, Peter wrote: > Peter wrote: > > Thank you, Lee, for your input. Somewhere in prior replies, I was advised NOT to use the same query in main and child forms. I was going to ask about that because, in one of Mervyn’s recent replies, he used the same query name (Customers1). If you check Function Pushbutton_onClick from 6/2/23, Mervyn shows exactly how he coded the passing of pat_no value from grid to edit form.  But…. > > You have discovered the precise problem I was having. If you select the first row in main form (Harry Potter), the edit form opens correctly. However, if you select any other person, either by pat_no or last name, the edit form opens with new pat_no but uses first row information to display datalinked entryfields in edit form.  The rowset is not changed. > It was this issue why Mervyn was advising me to sent all the code so he could debug. > Peter <snip>