>You exactly got the point Mark. I am very specific on details. This is the reason why I needed the exact data that were committed to the base tables. There are some procedures that needed precise and up to date records to process.
>
>I already tried to execute the sqlexec() again after the base tables were changed but still the record that is being returned to the query does not include the latest update of the base tables.
>
>What I do is to close the system and open it again and re execute the sqlexec() and by that, the last record modified will be included in the query.
>
>I guess I have to live by this fact...
>Thanks by the way....

You should not have to exit your app and get back in to re-execute the SQL. The "freshness" of the data is not dependent on when your current connection was established. If that were so, then any record the current user created would not be retrievable until that connection was terminated and re-established. What does matter is when the actual addition of the new record is committed to the database.

What may be happening is caching on the server. For performance reasons, servers are configured to cache parsed SQL and record sets for that matter. So what you may be seeing is the server already has your SQL from the SQLExec parsed, optimized and cached in memory. You the issue that exact same SQL to see if there are any new records. The server sees the same SQL is already in its cache. Now, I have never known this to be true, but the server may be returned the cache record set that corresponds to the cached SQL.

You can test server caching by altering the SQL you submit. The first time, submit the SQL in lower case and use the UPPER() function where needed if you have any literals you are searching for -- where country = upper('france'). Next submit the SQL in upper case and remove the upper function -- WHERE COUNTRY = 'FRANCE'. Between the 2 submittals, insert a new record and commit it to the database.