DataListView refresh

[stecosta66]

Hi Franz and Wolfgang,
this is a topic (althought in german) that I'm facing right now too. I'm porting my largest VO application base data from dbf to postgresql with vo2ado and bbrowser. I've many windows with bbrowser and with dbf no problem if any other workstation updates the data, with autorefresh I can see that changes reflects in bbrowser almost in real time. With postgresql is a different story. I don't know if cursor location (adUseServer and adUseClient) make any difference with underlying data when used with bbrowser to achieve the same functionality like with DBFs.

Any hint would be appreciated.

ciao
Stefano

[wriedmann]

Ciao Stefano,
I'll switch to English now.
The main difference between DBF and SQL data access is a completely different approach: when using a DBF file, your application opens the file physically and steps trough it. That means that if you skip to a new record, this records data is read from the disk, and if another user/application has modified the data, you will received the updated data (but it could be some delay for client or server side caching).
Using the bBrowser, only the records that are displayed in your grid are read. That is really memory efficient and, if not for a slow network, really fast. But moving through the data is causing data reading and network traffic (if the datasource is not on the local disk).
When using SQL data access, your application is requesting data from the server. This data is fetched to the memory (on the server or on the client). That makes it very efficient for small subsets of large databases, and, once the data is in the memory of the client, no more network traffic or data read is needed and you are working on disconnected data, so any change in the database will not be reflected on your local dataset.
Therefore I would always emphasize the fact that the change from DBF to SQL needs also always a change in the mind of the programmer because it is a completely different approach.
Wolfgang
P.S. in the last years, I have seen a change in the mind of many customers: about 20 years ago, customers requested fast incremental searchs, but now the are asking more and more for filters and not more for seeks. Therefore I'm changing many browser windows to listview windows even with underlying DBF data to permit better filters.

[stecosta66]

Ciao Wolfgang,
I'm aware of everything you said about transitioning from dbf to sql. I am just trying to find a way (I think Franz is in the same boat) to make a recordset 'act like' a dbf when viewed in a bbrowser, so that updating/adding made from other workstations can be seen from everyone else browsing data.

thanks again

Stefano

[wriedmann]

Hi Stefano,
to accomplish this you need IMHO some manual work, like reloading data from the disk at defined time stages, or whenever a window is shown.
I don't think this is impossible, but it needs some thinking.
Wolfgang
P.S. in one of my SQL based applications I'm executing the FillData() method in the Show() method, and, if the windows has focus, every x minutes. And I'm limiting the shown records to 100 or 200 (but it is a individual setting)

[robert]

Stefano,

Ciao Wolfgang,
I'm aware of everything you said about transitioning from dbf to sql. I am just trying to find a way (I think Franz is in the same boat) to make a recordset 'act like' a dbf when viewed in a bbrowser, so that updating/adding made from other workstations can be seen from everyone else browsing data.
thanks again

All SQL apps that I have worked on and have seen have this problem. They fetch the data from the server and cache the data locally.
The only way around this is to refresh the results every <n> seconds.

Most customers have no problem with this.

Robert

[FFF]

Robert,
i wonder, if one could not benefit from using the "notify"/"listen" functionality Postgres provides for distributing at least "single action" changes?

The NOTIFY command sends a notification event together with an optional “payload” string to each
client application that has previously executed LISTEN channel for the specified channel name
in the current database. Notifications are visible to all users.
NOTIFY provides a simple interprocess communication mechanism for a collection of processes
accessing the same PostgreSQL database. A payload string can be sent along with the notification,
and higher-level mechanisms for passing structured data can be built by using tables in the database
to pass additional data from notifier to listener(s). ...

[wriedmann]

Hi Karl,
even if you use that (really interesting) PG feature: you have to implement that in your application (or at least in your server classes).
Wolfgang

[lagraf]

Robert,
the problem is not to inform clients that data in db has changed. If you get this notice you have to refresh the dataset and that means that the DataListView, DataServer is new refilled. Then the marked rec is the first one in dataset and you have to position it to the last rec the user visited. And this fast and without flickering or scrolling.

[FFF]

Hi Wolfgang,
naturally - my thought was not so much pointed to the actual topic of this thread, as for the upcoming "universal" DBServer replacement Dev is working on. If they could incorporate this in the class or upper in RDD, i imagine a relatively seamless movement possible from DBF to SQL, better, to PG

[wriedmann]

Hi Karl,
I don't think PostgreSQL specialities will be integrated into the DBServer replacement - and IMHO most people will use MS SQL Server as backend for this, so I expect this will be the best supported database. (but some of us <g> will be using PostgreSQL so I'm sure it will also be supported).
PostgreSQL has too many nice features that other database servers don't have other than being rock solid.
Wolfgang
BTW: Alles Gute zum Geburtstag