NetTalk Central

Author Topic: Odd lookup behaviour  (Read 74 times)


  • Jr. Member
  • **
  • Posts: 50
    • View Profile
Odd lookup behaviour
« on: September 07, 2021, 07:31:15 AM »
Using NT 12.17

I have a form that allows a client record to be attached to a record in one of 2 ways, either select from an existing list (lookup) or add one on the fly that gets saved to a separate table to be validated later by another user.

So the form has a radio choice of existing or new then:

If new there are a selection of client fields to be entered manually including a drop list for titles from a Titles table (work perfectly)

If existing is selected an existing client a drop list is displayed and the client related entry fields become read only to display the selected client details. Again it all works perfectly, well most of the time on odd occasions the client fields are cleared after selection. I have narrowed this down to a drop list field, in this case the client title which is file loaded drop list (actually set to read only if existing client).

Here is a snippet of code from the Validate::lvClientCode Routine with the extra assign fields, the drop list field is lvClientTitleGUID. When the error occurs all the fields after lvClientTitleGUID in the list are blank, so if I moved it down several lines the fields above populate correctly, unfortunately I can't move it any lower than just before the pushevent so the clientcode is blanked. I have changed it to a queue loaded drop and all is well, could it relate to the fact that the title field drop value::.. routine opens and closes all the files including clients?

  do AfterLookup
  do Refresh::lvClientTitleGUID
  do Refresh::lvClientSurname
  do Refresh::lvClientFirstname
  do Refresh::lvClientDoB
  do Refresh::lvClientGender
  do Refresh::lvClientAddr1
  do Refresh::lvClientAddr2
  do Refresh::lvClientAddr3
  do Refresh::lvClientAddr4
  do Refresh::lvClientAddr5
  do Refresh::lvClientPostcode
  do Refresh::lvClientHomePhone
  do Refresh::lvClientMobilePhone
  do Refresh::lvClientEmail
  do Refresh::lvClientCode   ! Field is auto-validated
  do SendMessage

I hope someone can shed some light, if not I'll try to modify an example to recreate the problem, however it is very intermittent.



  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10581
    • View Profile
Re: Odd lookup behaviour
« Reply #1 on: September 07, 2021, 11:13:26 PM »
Hi Gordon,

This is one of those cases where it is impossible to really understand the problem without an example.
The fact that it is intermittent suggests that you are somewhere doing "2 things at once" and the timing can vary from one to the other. so yeah, an example will help, even if it is intermittent.



  • Jr. Member
  • **
  • Posts: 50
    • View Profile
Re: Odd lookup behaviour
« Reply #2 on: September 07, 2021, 11:51:32 PM »
Hi Bruce,

I will try to modify one of the example apps to recreate the problem, you are quite correct in that more than one thread is running for this page, while the validate of the lookup is running a second thread for this page also starts.

However the main difference I can see is that a file loaded drop opens and closes tables including clients and the queue version obviously doesn't, on occasions the the client record buffer is blank after the "do Refresh::lvClientTitleGUID" call, this is the file loaded drop list. It does appear to be timing dependant and is not an issue on my server with and SSD but it is on slower machines, I'm wondering if the second thread for this page is interacting with the first, however the tables are marked as threaded in the dictionary. Could the opening and closing of files cause a delay that allows the second thread to get out of step with the first, ie. something the second relies on is not complete when it runs or some other interaction?

I forgot to say this is using MSSQL tables.

« Last Edit: September 07, 2021, 11:53:49 PM by GordonF »