Hi Mike,

>Where internally the relations are based in the iClientId but in the UI the user will enter a cClientNumber

OK, the client Id is likely to be a surrogate value so, the user will not generally enter this information. So, we are talking about entering a domain specific character string representing the client a/c number. I don't understand why your query is intent on using a "BETWEEN" approach - this is only required when you want a range. If someone enters "35", then an appropriate WHERE clause could pull back everything that starts with "35" like "35", "3501", "354", "356", "3532" and so on. The more numbers provided, the more narrow would be the result set. I just cannot see why an operator would enter a number range from lower to higher to try to access a single client's account?

Either way, you are looking at this restriction in the LSQLPT cursor but not really thinking it through. You could easily configure a LSQLPT cursor that you can dynamically change its WHERE clause at runtime that will ultimately bring you back the integer record ID you want and use it as the basis of the re-query of your "fixed" updateable local view.

At the end of the day, all you want to get is the iClientId value. So, get what you want using a programmable dynamic WHERE clause, irrespective of whether its returned cursor is read-only and use the scalar value returned from the read-only cursor to "drive" the querying of your updateable view. They don't have to be the same cursor/view.

>I'm intrigued by your statement above, perhaps you could elaborate.

Hopefully, I have <s>.

>p.s. I sent you a private email, have you received it?

No.

Best