Dbf1 : Dataset is read-only.

0

Napisałem program w Lazarusie pod Windows10. Prosta baza danych oparta na plikach dbf. Sam sobie tworzy te pliki i działa super. Kiedy te pliki przeniosę na Linuksa openSuse 15.4 to owszem otwiera te pliki, ale jak próbuję je edytować coś dodać coś usunąć to wywala mi błąd "Dbf1 : Dataset is read-only." Jeżeli mój program pod linuksem sam je sobie utworzy to jest również ok, można je modyfikować, edytować itd. No i nie wiem co zrobić.

5

Może chodzi o atrybuty spróbuj polecenia chmod +rw nazwapliku — @kAzek 49 minut temu

ABSOLUTNIe najpierw analiza, pełne wyświetlenie info o plikach (flagi, owner, group) w jednym przypadku i drugim (jakieś ls -a lub podobne), dopiero potem ingerencja. Bez tego to strzelanie na oślep.

@mcz.rpm:
powiedz wyraźnie, uruchamiasz przekompilowany program na linuksie - czy słowa "Kiedy te pliki przeniosę na Linuksa" znaczą, że używasz Samby.
Bo Samba do flag pliku lokalnego dodaje swoje tryby/metody dostępu.
Podobieństwa plików Win/Linux local / Linux Samba się kończą na prostym otwarciu pliku. Wszelkie tryby dzielone to jazda bez bez trzymanki pod względem kompatybilnosci

Używasz archaiczej metody z zupełnie surowymi plikami - no to masz z nimi zmartwienie. Dla mnie to jest anty-ścieżka. Ostatni wybór pro-DBF owy którego byłem świadkiem, to z 15-17 lat temu
JUż SQLIte (nie lubię, o tym inny temat) to bardziej przetestowana ścieżka

5

W sumie to napisał to już @ZrobieDobrze powyżej, do tego jest to nie-do-końca odpowiedź na Twoje pytanie, ale klauzula sumienia nie pozwala mi przejść obok tej kwestii obojętnie ;)

Daj sobie spokój z "bazą danych" opartą na DBF'ach. Rozumiem, że nie masz potrzeby stawiania "prawdziwego" SQLa, ale do takich celów powstał SQLite. Działa 100 razy lepiej, wydajniej, jest to nowoczesne podejście (w odróżnieniu od DBF'ów, które powstały pod koniec lat 70-tych ubiegłego tysiąclecia) i daje Ci większe możliwości (chociażby SELECT ... WHERE). Implementacja tego niczym się nie różni od korzystania z DBF'ów, jeśli ograniasz DBF'y to z SQLite też sobie poradzisz.

Serio - nie rób sobie krzywdy, nie idź tą drogą.

https://wiki.freepascal.org/SQLite - tutaj masz ładnie opisane, jak to działa w Lazarusie.

0

Też mi się wydaje, że to jest związane z właścicielem, ale tak czy inaczej dzięki za mądre rady, że warto by się zainteresować SQLite i pójść w tym kierunku. Póki co to baza danych na DBF na moje niewielkie potrzeby w zupełności mi wystarcza, a w SQLite zapewne się zagłębię.

2

Pozwolę sobie powiedzieć coś w poprzek. Zgadzając się, że dbf to archaik (przede wszystkim z powodu braku UTF-8) wcale nie uważam, że musisz od razu strzelać z armaty do komara. Jeśli aplikacja jest niewielka, to zamiast SQLite proponuje użyć TBufDataset. Gdy korzystasz z DataSet-a nie ma właściwie znaczenia co jest pod spodem (zresztą po to wymyślono DataSety). Wybierasz potomka, a metody i właściwości są w zasadzie te same – nie musisz się nic uczyć na nowo. Obojętne czy to jest Postgres, Oracle czy właśnie BufDataSet. Jak dobrze napiszesz, to czasami nie ma nawet potrzeby przerabiania kodu (ostatnio ktoś przywołał na forum typy generyczne) jeśli zmienisz „silnik” na inny. Przy TBufDataset masz wszystko co potrzeba, zwróć tu uwagę na metodę SaveToFile i LoadFromFile. Swoja drogą jeśli aplikacja ma pracować offline to dość naturalne jest trzymanie lokalnej kopii danych właśnie BufDataset i potem kopiowanie jej na serwer SQL. Prosta procedura, która to robi ma parę linijek. Jak już musisz koniecznie SQL lokalnie, to może jednak FireBird (zobacz IBX), ale chyba odradzam w takich zastosowaniach.

3

nie uważam, że musisz od razu strzelać z armaty do komara

Pozwolę sobie odnieść się do tego fragmentu ;)
Ogólnie to nie uważam, żeby wrzucenie SQLite było strzelaniem z armaty. OK, jakbyśmy poradzili, żeby kolega postawił Postgresa na VPS, albo skorzystał z jakiegoś AWS to by był ewidentny overkill. Ale sam SQLite działa OOTB w Lazarusie, możesz sobie skorzystać (mój ulubiony sposób) z malutkiego wrappera - https://www.itwriting.com/blog/articles/a-simple-delphi-wrapper-for-sqlite-3, obsługa tego jest trywialna, ktoś, kto nie miał z tym do czynienia w pół godziny ogarnie temat. A od razu dostajesz wszystkie rzeczy, które oferuje SQL - typu SELECT i dowolne warunki, UPDATE, INSERT itp.

1 użytkowników online, w tym zalogowanych: 0, gości: 1