Re: buttons affecting default queries..?

I've always found it useful to add new items as ordinary text items initially, get all my basic logic working, then convert them to some kind of GUI widget and attend to the specific triggers, properties etc. as a final step. Much better transparency and not as likely to run into this kind of problem. In your case, this approach would mean that you can be sure the query is working fine with the additional item of data, so it must be something specific to the radio button widget.

Martin

Andrew Hurst wrote:

> Daniel Morgan wrote:
>
>> Andrew Hurst wrote:
>>
>>
>>> Another bit of information, I was able to find out. It appears that in
>>> an ON-POPULATE-DETAILS query there is a statement that will return if
>>> System.Record_Status is NEW or INSERT. When run through the debugger,
>>> its set to NEW. This is when I supply a parameter of the proposal to
>>> retrieve. It should be QUERY, as I understand it. I'm going to keep
>>> looking, but if anyone has any suggestions on where to look on why or
>>> how that would change, I'd appreciate it.
>>>
>>> Thanks for putting up with my constant posting...
>>>
>>> -Andrew
>>>
>>> Andrew Hurst wrote:
>>>
>>>> Karsten Farrell wrote:
>>>>
>>>>
>>>>> Andrew Hurst wrote:
>>>>>
>>>>>
>>>>>> I have a button that when I added it, stopped its forms' query from
>>>>>> working, and I don't know why. Thanks in advance for all help you
>>>>>> can give me. Here is my situation:
>>>>>>
>>>>>> I have a form, that lists proposals. By clicking on the year of the
>>>>>> proposal it takes you to a detail form for that proposal.
>>>>>> Essentially a "select <columnlist> from proposals where proposal_id =
>>>>>> <clicked_proposal_id>" is executed to populate the detail form.
>>>>>> This
>>>>>> has been working fine, i.e. it brings up the correct proposal in the
>>>>>> detail form, and all is happy. I recently added a button to the
>>>>>> proposals detail form, to print it out with a Report. For this I
>>>>>> added 2 alerts, 1 program unit, and the button with a
>>>>>> WHEN-BUTTON-PRESSED trigger. The trigger just calls the program
>>>>>> unit.
>>>>>>
>>>>>> But here lies the problem: Now when I run the ALL_PROPOSALS form,
>>>>>> and it lists all of the proposals, when I click on a year for a
>>>>>> specific proposal I get a "FROM-40350: Query caused no results to be
>>>>>> retrieved" error. I've been trying to figure out why, but I don't
>>>>>> see anything that I have changed that might cause this. I haven't
>>>>>> modified the DEFAULT_WHERE, and I didn't add any columns to the block
>>>>>> for this query.
>>>>>>
>>>>>> The correct query appears to be executing, as I've go so far as to
>>>>>> sniff the network for the connection, and look whats running. I can
>>>>>> see the correct query float by, then I can run it by hand in TOAD
>>>>>> with no problems.
>>>>>>
>>>>>> Does anyone have any idea what could cause this? Why would adding a
>>>>>> button, a trigger, and a program unit cause the query to fail? Is
>>>>>> there some setting that might have been flipped that I'm not
>>>>>> aware of?
>>>>>>
>>>>>> Thanks for the help, and let me know if you need more information.
>>>>>>
>>>>>> -Andrew Hurst
>>>>>>
>>>>>
>>>>> I assume you put the WHEN-BUTTON-PRESSED trigger at the correct level
>>>>> (button level)? If it's at the wrong level (where your year-click is),
>>>>> you will run the wrong query (or at least not the one you expect).
>>>>> This is just "grasping at straws" since adding what you did to the
>>>>> Form shouldn't break it.
>>>>>
>>>>
>>>> I should have clarified, these are two different forms. There is
>>>> ALL_PROPOSALS which lists all of the proposals, then there is PROPOSALS
>>>> which gets called when you double-click on the year in the
>>>> ALL_PROPOSALS
>>>> form.
>>>>
>>>> With that said, I went back and checked again. The problem didn't
>>>> surface after addition of the push button. It surfaced after the
>>>> addition of a radio group. Sorry for the wrong description of the
>>>> problem... (yay for versioning, cvs, and checking in after every new
>>>> feature, though :). I'm still trying to figure out why it would not
>>>> return any data, though.
>>>>
>>>> Here is the really odd part I just remembered (and verified again):
>>>> When
>>>> I set up the network sniffer, and try to double click on the year
>>>> to get
>>>> into the report, it gets some of the data, then it returns
>>>> ORA-01403: no
>>>> data found. This is what I see in the traffic:
>>>>
>>>> ... stuff I can't tell what it is...
>>>> the (correct) query to get the data goes to the server, with :1 for the
>>>> proposal_id. Shortly (as in 20 chars or so later) the correct
>>>> proposal_id goes by as well.
>>>> The server responds with a list of columns from the table, about 20 or
>>>> so characters apart (each column name).
>>>> The server starts returning the correct data from the proposals table,
>>>> everything I've asked for.
>>>> About 1/3 of the way through the data, it ends with 'ORA-01403: no data
>>>> found'.
>>>>
>>>> So it appears that maybe its getting too much data back. Or maybe
>>>> there
>>>> is a timeout set too low? This has never been a problem before, and I
>>>> can't see why a varchar2(20) column would really push us over the
>>>> limit...
>>>>
>>>> Thanks for the help, and sorry for the initial confusion.
>>>>
>>>> -Andrew
>>>>
>>>
>>
>> One possibility is that the radio buttons have values precluded by a
>> check
>> constraint on the table ... or the values in the table conflict with
>> the values
>> in the radio buttons ... or you have nulls in your data and your
>> radio buttons
>> haven't a clue what to do with them.
>
> That last one was it. I didn't have "Mapping of Other values" set in
> the Radio Group Property Palette. I had the "initial value" set, and
> I thought that would do what I needed. doh.
>
> Its times like these that make me wish there was a better error
> message than "No data found" for this. Maybe "No matching data
> found", it shouldn't be that hard :/
>
>> BTW: Is there any version information here?
>
> Forms 6 connecting to an oracle 8i db.
>
> Thanks for all your help, and reading my working through the problem :)
>
> -Andrew
>
>>
>> Daniel Morgan
>>
>
Received on Sat Oct 26 2002 - 02:52:49 CEST