BDE Net Dir – problem po przeniesieniu programu pod Tokyo

Mam problem po przeniesieniu programu pod Tokyo.

Przy dostępie do jednej z tabel Paradox program próbuje utworzyć plik PDOXUSRS.LCK w C:\Windows\System32 i się wywala, bo nie ma dostępu. Z tego co wiem, te pliki LCK BDE powinno tworzyć w katalogu wskazanym przez Net Dir, więc ustalam je na bieżący katalog programu, powiedzmy:

Session.NetFileDir:='C:\PROGRAM'

i działa dobrze. Ale w jednym miejscu programu jakby ignorował to NetFileDir i działa jak wyżej. Czy obiekt Session kontroluje wszystkie tabele? Czy jakaś tabela może mieć swój prywatny Session?

System nie pozwoli zmodyfikować zawartości na dysku C:, jeśli aplikacja nie została uruchomiona z prawami administratora lub jeśli te uprawnienia nie zostały podniesione w trakcie sesji programu. Dlatego też nieważne, czy apka będzie próbowała pisać w C:\system32\, czy w C:\Program Files\ – bez uprawnień dostaniesz odmowę.

Dane wymagane do przechowywania na dysku i modyfikacji, gromadzi się w specjalnie stworzonych do tego celu katalogach, o czym możesz pzeczytać w dokumentacji.

1. NetFileDir powinno być ustawiane jak najwcześniej, zanim otworzysz jakąkolwiek tabelę
2. NetFileDir powinno wskazywać na katalog sieciowy jeśli na bazie pracuje więcej niż jeden komputer
3. BDE jest stare, brzydkie i ogólnie be

BTW ja pod XE8 nawet nie mam już BDE...

Zrobiłem pewne zmiany (wstawiłem własny obiekt TSession) i chciałbym przetestować, czy BDE już nie tworzy żadnych własnych plików w C:\Windows\System32
Macie jakiś pomysł jak to zaobserwować? Można by zmienić atrybuty katalogu na Read-Only, ale boje się, że Windowsy się wysypią.
Może jest jakieś narzędzie, które ostrzega, ze ktoś tworzy plik w obserwowanym katalogu?

@coder-bis: zobacz tutaj – dziesięć programów, dobre opisy ze zrzutami ekranu.

Wydaje mi się, ze dotarłem do wiedzy, która wyjaśnia to zjawisko, otóż:

Obiekt Session w momencie tworzenia przyjmuje swoje PrivateDir jako bieżący katalog.
W niektórych wersjach Windows jest to katalog EXE-ka, a w niektórych nie wiedzieć czemu przyjmuje Windows\System32 i tam próbuje utworzyć plik LCK, i się wywala.
Rozwiązanie które zadziałało: ustawić bezpieczny katalog roboczy poprzez ChDir przed pierwszą operacją bazodanową.

coder-bis napisał(a):

W niektórych wersjach Windows jest to katalog EXE-ka, a w niektórych nie wiedzieć czemu przyjmuje Windows\System32 i tam próbuje utworzyć plik LCK, i się wywala.

Wywali się tylko wtedy, gdy nie ma uprawnień do zapisu w tej lokalizacji.

Na starych systemach (takich jak XP), na domyślnych uprawnieniach można wprowadzać modyfikacje na dowolnej partycji i w dowolnym katalogu (z wyłączeniem tych systemowych, których nawet otworzyć się nie da). Dlatego mnóstwo programów tworzyło pliki obok pliku wykonywalnego. Chyba że administrator zablokował możliwość tworzenia plików w danej lokalizacji.

W systemach wyposażonych w usługę UAC nie można takich rzeczy robić.

Rozwiązanie które zadziałało: ustawić bezpieczny katalog roboczy poprzez ChDir przed pierwszą operacją bazodanową.

Możliwe, że program nie spowoduje błędu, jeśli uruchomisz go z uprawnieniami administratora. Oczywiście jeśli aplikacja przy rozruchu nie wymusza zwiększenia uprawnień.