Converting Set Filters to Remote Views

[stanlyn]

Hi,

Using remote views, what does the syntax look like to convert "set filters" to something more for remote views and how are they tied to the form's datasource?

This code is in a combobox where the user selects what is to be shown.

Case This.DisplayValue = 'Available'
	Set Filter To rv_list.registered <> 1
	Go Top

Case This.DisplayValue = 'MeterLocked'
	Set Filter To rv_list.meterlocked = 1
	Go Top

Case This.DisplayValue = 'Publicly List'
	Set Filter To rv_list.publicly_list = 1
	Go Top

Thanks, Stanley

 

[stanlyn]

Q3: single row update only cares for single row, yes. A view requery requires no buffered changes. None at all. If you're only interested in saving the one row, then tablerevert() all other changes, then you can also requery.

Chriss, don't try to see the end result as my example was to verify if the logic was correct (doable), regardless of the final result. Your original post suggests that we can have two buffering statuses concurrently, one for row and one for table, and maybe one for each of the 5 types, so long as we issue the cursorsetprop() before using them?

You quickly saw the end result was only one record should be saved, therefore reverting all others. What I was asking for is whether the progression of the code was legal, as in making save/revert decisions on the fly while traversing a code block without considering the current state of a buffer.

I'll play with this in a test as its hard to explain to you, yet easy for me to know what the question is...

hanging between row and table buffering is no good idea, I think. What happens to uncommitted changes of a table buffer when you switch to row buffer is, I assume they are automatically reverted or committed. I don't know, or an error is thrown quite like that of view requery when there is something buffered.

I will test a lot of this as understanding this will go a long way working with views.

then the logic would say, since your tableupdate() only updates 1 row, buffered changes are in other rows.

Chriss, we are discussing this because of this suggestion, which raised these related questions...

Is it perhaps really just a single misconception that requery of a view only refreshes he current row?

I understand that a requery() does a re-read of all the underlying data matching the select or parameters, not just a single current row. Is this correct?

Thanks, Stanley

 

[Chris Miller]

Your original post suggests that we can have two buffering statuses concurrently

No, what did I say that suggests that? A workarea can only have one buffer mode You switch modes, and you usually only use tablebuffering. The other mode differences are about locking. And some changes are not possible, some modes are also not available for views. Take a look into the help chapter for the details.

Regarding buffering in itself and isolated for itself there are only two modes. The other modes are just mixing in the possibilities about locks. Pessimistic and optimistic. That has nothing to do with buffers.

Chriss

 

[Chris Miller]

The whole locking part of this is useless for a remote backend. An RLOCK or FLOCK is for a DBF file not for anything else.

PS: I'm sure someone will disagree, I'll stick to this, as thinking about locking with database backends other than VFP is best handled in the respective native manner. Usually the topic is more a topic of transactions and isolation level anyway.

Chriss