DBF - śledzenie aktualizacji tabeli

Mam aplikację, która pracuje na własnej bazie (dbf) na którą nie mam żadnego wpływu (aplikacja obca). "Z boku" podłączam się aplikacją własną, którą muszę sprawdzać w określonym interwale (<1 sek.) czy pojawił się nowy rekord w obserwowanej tablicy. W związku z tym ma 2 pytania:

1. Czy jest jakaś metoda lepsza od on timer ?
2. Co może być powodem tego, że próba odczytu z tej tabeli skutkuje "wieszaniem się" tej aplikacji (obcej),

1. do DBFów nie nadaje się BDE. Możesz spróbować darmowych komponentów jak TDBF ale polecam komercyjne - Apollo (choć ma problemy z indexami NTXowymi jeśli są w nich pl znaczki) lub Advantage (nie testowałem).
2. mam podobny problem i po przyjrzeniu się sprawie widzę takie hinty
   a) w DBFie, w nagłówku jest pole, w którym powinna być data ostatniej modyfikacji (nie wiem, czy wszystkie programy ją zapisują)
   b) można monitorować zmiany w katalogu (zobacz sobie komponent TShellChangeNotifier) tylko nie wiem, czy przy zmianie zawartości pliku jest on uaktywniany
   c) nowy rekord zawsze jest dopisywany na końcu tabeli, więc zamiast czytać całą tabelę aby znaleźć dopisany rekord można czytać ją od końca (BEZ indexów)
   d) porównywanie można robić na zasadzie algorytmu diff z tym, że im większe pliki tym dłużej to będzie się działo no i trzeba mieć kopie pliku dbf do porównania.

Co do zawieszania aplikacji to napisz jakie komponenty, w czym pisana ta druga aplikacja i czy są one na tym samym kompie co DBFy

Widzę 2 sprawy:

1. Czy możesz założyć trigger OnInser, Before Insert czy co tam masz związanego z wykrywaniem inserta? Jesli tak to tylko kwestia obsługi triggera, czy możesz do delphi "pociągnąć" obsługę czy też musisz obsłużyć na poziomie BD (np przez osobną tabele w której notujesz wszelkei inserty wraz z czasem insertowania). To akurat zależy od komponentów jakich używasz.
2. Zawieszanie aplikacji: Możesz robić 2 brzydkie rzeczy, jedna to taka że tak często sprawdzasz że obciązenie bazy danych idzie w kosmos. Druga to fakt, że w zlaezności od tego jak napisano tamtą aplikację, w zalezności jakich ty i tamta aplikacja transakcji uzywa możesz blokowac rekordy tabeli niezbędne dla poprawnego działania tamtej. Kiedyś na praktykach dostałem po uszach za robienie standardowyc selectów z wieloma joinami na dużej BD (ZUS) na której trwało standardowe przetwarzanie danych. Długi select, jeszcze w paskudnej transakcji może sparaliżować pracę innych użytkowników na BD, a od tego jak sobei poradzą inne apliakcje zależy jak dobrze je napisano.

Generalnei jeśli uda się wykorzystać jakiś trigger, event - nie wiem czym dysponujesz i sam nie dociążasz BD za mocno to powinno bezboleśnie ruszyć.

Transakcje i trigery w DBF-ach? No co Ty...

Niestety nie wiem z użyciem jakich komponentów napisana jest ta aplikacja. DBFy są na tym samym kompie co aplikacje. Spróbuje jeszcze użyć komponetów o których piszesz. Tabel tej aplikacji (obcej) używam w trybie tylko do odczytu. Odczytuję kolejne (co 1 sek) rekordy z tabeli (jeśli się pojawią) od ostatnio odczytanego, którego pozycję ustalam przy starcie aplikacji (od końca).

daban napisał(a)

Widzę 2 sprawy:

1. Czy możesz założyć trigger OnInser, Before Insert czy co tam masz związanego z wykrywaniem inserta? Jesli tak to tylko kwestia obsługi triggera, czy możesz do delphi "pociągnąć" obsługę czy też musisz obsłużyć na poziomie BD (np przez osobną tabele w której notujesz wszelkei inserty wraz z czasem insertowania). To akurat zależy od komponentów jakich używasz.

DBFy to nie baza SQLowa to baza płaska, plikowa. Tu nie ma czegoś takiego jak trigger, procedura, SQL (chociaż są serwery, które potrafią z DBFów zrobić bazę SQLową). Tu najczęściej działa clipper albo foxpro, zazwyczaj dosowe.

2. Zawieszanie aplikacji: Możesz robić 2 brzydkie rzeczy, jedna to taka że tak często sprawdzasz że obciązenie bazy danych idzie w kosmos. Druga to fakt, że w zlaezności od tego jak napisano tamtą aplikację, w zalezności jakich ty i tamta aplikacja transakcji uzywa możesz blokowac rekordy tabeli niezbędne dla poprawnego działania tamtej. Kiedyś na praktykach dostałem po uszach za robienie standardowyc selectów z wieloma joinami na dużej BD (ZUS) na której trwało standardowe przetwarzanie danych. Długi select, jeszcze w paskudnej transakcji może sparaliżować pracę innych użytkowników na BD, a od tego jak sobei poradzą inne apliakcje zależy jak dobrze je napisano.

Generalnei jeśli uda się wykorzystać jakiś trigger, event - nie wiem czym dysponujesz i sam nie dociążasz BD za mocno to powinno bezboleśnie ruszyć.

No to sorki, faktycznie moa rada może być do kitu, choć słysząłem o bazach sqlowych działających na BDFach. Przyznaję nigdy nie używałem więc nie znam specyfiki :)