TOPIC:

Wenn ich in einem DataListView eine SQLTable darstelle und auf einem anderen Arbeitsplatz einer dieser angezeigten Datensätze geändert wird, kann ich diese geänderten Daten dem User irgendwie anzeigen?
- entweder den DataListView refreshen
- oder den Datensatz auf den ich drauf positioniere aktualisieren

Hallo Franz,
in diesem Fall musst Du dafür Sorge tragen, dass die Daten neu gelesen werden, d.h. das SQL-Select neu ausgeführt wird.
Wieweit das die SQLSelect-Klasse aber bereits von alleine macht, kann ich Dir nicht sagen.
Wolfgang

Die Variante ist halt unschön, denn jedesmal wenn jemand einen Datensatz ändert, wird ihm quasi der Boden unter seinem Hintern weggezogen und der Cursor steht wieder auf dem ersten Satz des Datasets.

Besteht das Problem auch bei Verwendung des bBrowsers oder bei DBFs?

Hallo Franz,
bei DBFs hast Du das Problem nicht, weil dort der Satz frisch und direkt aus der Tabelle gelesen wird, während bei SQL eine Abfrage gestartet wird und der Server ein Resultat zurückgibt. Das ist auch mit ein Grund, warum DBF bei größeren Datenmengen so viel langsamer als SQL ist.
Das mit dem Boden unter den Füßen weggezogen ist Dein Job: Du musst halt den aktuellen Satz vor dem Refresh speichern und danach wieder anspringen. Dazu solltest Du den eindeutigen Key des Satzes verwenden.
Das ist aber auch so, wenn Du so wie ich mit normalen ListViews (also nicht DataListView) auf DBF-Daten arbeitest.
Wolfgang

Wenn ich das Datset neu einlese und den Cursor auf den Datensatz stellen möchte, auf dem der User zuvor stand, dann geht das nur indem ich die Sätze durchskippe. Würde ich wie bei DBFs einen Seek drauf machen, dann könnte ich ab dem gefundenen Datensatz nicht mehr zurückblättern, weil durch den Seek ein neues Dataset beginnend mit dem gesuchten Satz gemacht wird. Da muß ich mal ausprobieren, wie lange das Skippen bei ein paar hundert Sätzen dauert, und natürlich die Anzeige dabei unterbinden.

Hallo Franz,
ich würde hier den DataListView komplett vergessen und das mit einem normalen ListView machen.
Wolfgang

Ich habe immer einen DataListView für die Übersicht und daneben die Details für die Eingabe des markierten Datensatzes, beide arbeiten mit dem gleiche Server, sodaß sie miteinander skippen.

Welche Vorteil hätte ein ListView anstelle des DataListView? Nachteil wäre ja, dass ich alles manuell aufbauen und synchronisieren muss. Wie schauts dabei mit dem Sortieren, Filtern und suchen über alle Spalten aus?

Hallo Franz,
wenn Du alles manuell machst, hast Du wesentlich mehr Kontrolle über das Ganze.
Genau dasselbe gilt auch für Filtern, Sortieren usw.
Besonders mit SQL bewährt es sich, die Daten in einen ArrayServer einzulesen und dann nur mehr im Speicher zu arbeiten. Änderungen kannst Du dann gezielt in die Datenbank schreiben, bzw. genauso gezielt aus der Datenbank lesen.
Wolfgang

Hallo Wolfgang auch schon munter?
Das mit dem ArrayServer verhindert aber nicht, dass die Daten im ListView nicht aktuell sind, wenn durch PHP Apps andere User inzwischen Daten verändern. Ich könnte zwar die Daten im Array aktualisieren, wenn das geschieht, aber die Anzeige im ListView würde sich erst nach einem Refresh aktualisieren.

Hallo Franz,
spätestens 5:30 bin ich am PC.....
Das mit dem Ändern von Daten durch andere Benutzer wirst Du anders als durch regelmäßige Refreshs nicht auf die Reihe bekommen.
Das einzige, was mir sonst noch einfallen würde: per Datenbank-Trigger ein Notification-Log erstellen und das regelmäßig auslesen.
An die Funktionsweise von einem bBrowser auf einer DBF-Datenquelle kommst Du da aber nur mit großem Aufwand hin.
Das ist systembedingt. Meines Wissens nach hat der VO DataBrowser im Hintergrund da irgendwas gemacht, d.h. beim Bewegen innerhalb des Grids den aktuellen Satz neu nachgeladen oder so ähnlich. Ich habe das aber nie eingesetzt - bin sehr schnell auf GridPro und dann bBrowser umgestiegen, und mit SQL sowieso nur auf ListViews (nicht DatalistView). Das nutze ich mittlerweile auch immer mehr mit DBFs als Datenquelle.
Wolfgang

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

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.

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

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)

Stefano,

diobrando wrote:

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

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). ...

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

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.

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

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