Barbara
>are you aware that SELECT will never look at buffered data?
Learn something new every day.

Actually all I was trying to do was get a calculation from two different tables to determine how to continue with the posting process. The select statement was selecting into an array. My framework depends on table buffering to save the data. I will have to do some procedural code to get the answer.

Thanks again.

>It sounds like you're trying to write over the cursor in which you've made your changes with the new SELECT. I'm not sure why you'd do that, but, are you aware that SELECT will never look at buffered data? So, even if you're trying to create a new cursor with your SELECT, it won't see any of the pending changes. It sounds like you really don't want to use buffering on this cursor, especially if you don't want the changes to be saved.
>
>>Thanks for your reply Barbara.
>>
>>What I am tring to do is do some calculations before saving. Since I am rolling my own insert and update statements, doing a tableupdate will change the cursor state so I will not know that the data changed and the data will not be saved. I guess I will have to do soming other than a select statement.
>>
>>>You'll get the same problem if you're using a view, in which you've modified data and you try to requery(). You need to either Tableupdate or Tablerevert before you re-rerun the SPT.
>>>
>>>>Hi All
>>>>
>>>>I ran into a new one to me. I am going against a Sybase database on this project and my framework is using only SQL passthrough. I set cursor buffering to 5 so I can find any changed columns using getnextmodified() and getfldstate(). What I have just found is if I have inserted data into a cursor (recno < 0) that vfps select statement can't retrieve the data. Is there a way around this?
>>>>
>>>>Thannks for your help.