Record not found 5

[wasatchconsulting]

I have a browse form with a "contains" locator. I am getting a behavior that is different when using external URL verses using "localhost".

On the localhost, if I type in a string to search and press the "Enter Key" and then I need to click on the row twice to get it to pop up.

Using the external URL, it I type in a string to search and press the "Enter Key" and then I click on the row it gives me "Record Not Found (5) error 0 from Key". Close the error and click on the row again and all is well again.

It appears that there is "timing" issue only if the "Enter Key" is used. The localhost just deals with the issue different verses using the external URL. If I use the "Tab Key" in both, the behavior is just fine. Enter the string and press tab and then click on the row and it works the first time. It only appears to be an issue when using the "Enter Key".

If the external URL acted like the localhost, I would be okay, but the end user is getting the error. It becomes more difficult to test an "example" app using an external URL.

I am using Nettalk 7.22

Any thoughts as to what this issue might be, I would appreciate it.

Thanks
Ken Watts
Wasatch Consulting Services

[bshields]

Hi,

The nettalk server really shouldn't have different behavior if you access it via localhost versus an external IP, to it they are all just ports!

The external IP process could generate different behavior, based upon travelling through firewalls and/or proxies. But, under most circumstances lots of other stuff would also be going wrong.

I know this isn't very helpful, but i'd take a step back, and do some more testing and also try and align the localhost versus external IP test environments exactly.

Regards
Bill

[Bruce]

Hi Ken,

There's no difference in behavior between the two servers, but there may be a difference in speed. (As far as I can tell there's no different between the Tab and Enter keys - that may be a red herring.)

When you complete the locator (enter, or tab etc) then the new request is set to the server. when the server response is received the visible table is replaced with the new contents of the browse.

If the response is fast, then there's no opportunity for the user to click on the "old" table, or perhaps click on a button in the old table, before the new one arrives. If it's a bit slower then there is an opportunity for them to do that.

On the server side, the old table has been forgotten, and the new one "remembered" so if the user clicks on the table after the old one has been forgotten - especially say the click to go to a form - then there's an error when they get to the form record. (because the id linking that browse line to a table record has been forgotten.)

So how to fix? In 7.23 I've tweaked the code a bit so that when the table is "invalidated" by the locator request (or by a navigation request) it fades out a bit so there's a visual indication that is is "invalid". When the new table arrives it is back to normal opacity. This will hopefully give the user a clue that "something is happening" and he needs to wait a moment to click on the row.

cheers
Bruce

[wasatchconsulting]

Bruce,

I looked into this a little closer and found that it happens when I check "Link to Form" box on the "On Click" tab for a field. I noticed that the only thing different is "class='nt-fakeget'" is added to the code for the packet.

Locally, the issue is manifesting itself by requiring the user to click on the link twice to get the form to popup. Externally, it gives me the error 5.

If I use a "modify" button instead, the problem does not happen, but the client does not want to require the user to click on the row and then click on the modify button, they just want to click on the row and so this becomes an issue.

I modified example WEB (2) with a contain locator and checked the "link to form" box. This is giving me the same behavior as the local side. Maybe the fact I am using SQL has to with the error 5, but the example requires me to click on the row twice before it comes up, whereas the "change" button will open the form immediately.

Any thoughts will be appreciated.

Thanks
Ken Watts
Wasatch Consulting Services

[wasatchconsulting]

Upon further review I have found a difference in behavior with the tab key verses the enter key in a search.

If the row has the "Link to Form" check box clicked, you have the option of clicking on the row to open the form. With that set, if you enter a string in the search field (using contained in this case) and use the "Tab" key, you can then click on the row and the form opens with the first click. On the other hand, if you enter a string in the search field and then use the "Enter" key, then you must click on the row twice in order for the form to open.

This seems to be at the root of the issue I am experiencing only, when I click on the row after using the "Enter" key, it gives me an error instead of making me click on the row twice. If I close the error and click on the row again, then the form comes up.

The issue only appears to be an issue on the first row you click on after you hit the "Enter" key. Any other click in the same search works just fine.

I used the attached example to test this with as well. I added the locator and checked the box in the example and received the same behavior.

Thanks
Ken Watts
Wasatch Consulting Services

[attachment deleted by admin]

[Bruce]

please always include the dictionary (and ideally tps files as well) when posting an example.
I can't open the app in your dict, without your dictionary because the dict was converted from C6 and is now unique on your machine for that app.

cheers
Bruce

[wasatchconsulting]

Sorry about that
Ken

[attachment deleted by admin]

[Bruce]

fixed in 7.25