Calc – współdzielenie pliku

[andro]

Wobec tego wszystko jasne. Podziękowania również dla użytkownika @Jermor, który jak widać czuwa nad tym, co tu się wyrabia
Co do ukrywania logów, to w zupełności to wystarczy.

[Jermor]

Napisałem sobie kiedyś kilka funkcji, podsyłam je wam koledzy do wykorzystania. Może się przydadą.
Większość z nich napisałem z myślą o tych, którzy lepiej się czują z adresami typu A1, B2:C4.
W tych funkcjach zamiast takiego adresu można wstawiać nazwę przypisaną do komórki lub obszaru co powoduje, że w przypadku przeniesienia tej komórki w inne miejsce arkusza, makro nadal będzie działało prawidłowo.

Funkcja, która zwraca numer ostatniego wiersza albo ostatniej kolumny w arkuszu. To zmodyfikowana wersja LastUsedRow.

Kod: Zaznacz cały

Function GetLastUsed(oSheet as Object, Optional Co As string) as Long
REM zwraca ostatni numer wiersza(W) albo kolumny (K) w arkuszu,
REM który jest argumentem funkcji.
Dim oCell As Object
Dim oCursor As Object
Dim aAddress As Variant
If IsMissing(co) Then co="W"
Co=UCase(co)
oCell = oSheet.GetCellbyPosition(0, 0)
oCursor = oSheet.createCursorByRange(oCell)
oCursor.GotoEndOfUsedArea(True)
aAddress = oCursor.RangeAddress
Select Case co
	Case "W"
	GetLastUsed = aAddress.EndRow
	Case "K"
	GetLastUsed = aAddress.EndColumn
	Case Else
	MsgBox "Zły argument wyboru wartości:" & chr(13) & "W - wiersz, K - Kolumna", 48, "Błąd argumentu" : stop
End Select
End Function

Adres komórki aktualnie aktywnej.

Kod: Zaznacz cały

Function komorka (Optional co as string)
Rem Funkcja podaje dane adresu komórki aktywnej
Rem w zależności od parametru: w - wiersz, k- kolumna, a - adres względny
Rem  b - adres bezwzględny
Rem numery wiersza i kolumny są liczone od 0
Dim sa as string
If IsMissing (co) Then co="A"
oSel = ThisComponent.getCurrentSelection()

If oSel.supportsService("com.sun.star.sheet.SheetCell") Then
	co=UCase(co)
	Select Case co
		Case "W"
		komorka=oSel.CellAddress.row 
		Case "K"
		komorka = oSel.CellAddress.column 
		Case "A"
		sa=oSel.absolutename
		sa= mid(sa,instr (1,sa,".$")+2)
		komorka=""
		For i=1 to len(sa)
		if mid(sa, i, 1)<>"$" then komorka=komorka & mid (sa, i,1)
		Next
		Case "B"
		komorka=oSel.absolutename
		Case Else
		MsgBox "Zły argument wyboru wartości:" & chr(13) & "W - wiersz, K - Kolumna, A - Adres względny, B - adres bezwzględny", 48, "Błąd argumentu" : stop
	End Select
ElseIf oSel.supportsService("com.sun.star.sheet.SheetCellRange") Then
	MsgBox "Zaznaczony jest obszar komórek",48,"Zaznaczony obszar" : stop
ElseIf oSel.supportsService("com.sun.star.sheet.SheetCellRanges") Then
	MsgBox "Zaznaczono kilka obszarów." &chr(13) & "Ilość zaznaczonych obszarów: " & oSel.count(), 48, "Zaznaczony obszar" : Stop
End if
end Function

Wstawianie ciągu do komórki

Kod: Zaznacz cały

Sub wstaws (ark as string, gdzie as string, co as string)
rem procedura wstawia łańcuch znakowy do wskazanego miejsca
rem ark= nazwa arkusza
rem gdzie= nazwa komórki jako np b12
rem co= łancuch znakowy
ThisComponent.Sheets.getByName(ark).getCellRangeByName(gdzie).setString(co)
End Sub

Wstawianie liczby do komórki

Kod: Zaznacz cały

Sub wstawn (ark as string, gdzie as string, co)
rem procedura wstawia wartość do wskazanego miejsca
rem ark= nazwa arkusza
rem gdzie= nazwa komórki jako np b12
rem co= wartość, jeśli bezpośrednio to znakiem dziesiętnym jest kropka
ThisComponent.Sheets.getByName(ark).getCellRangeByName(gdzie).setValue(co)
End Sub

Kopiowanie z obszaru do obszaru

Kod: Zaznacz cały

sub kopiuj (z_ark as string, z_adr as string, do_ark as string, do_adr as string)
rem Makro kopiuje dane z obszaru komórek z do miejsca do
rem z_adr podać jako np b3:c12, do_adr jako jedna komórka
zrodlo=ThisComponent.Sheets.getByName(z_ark).getCellRangeByName(z_adr).RangeAddress
cel=ThisComponent.Sheets.getByName(do_ark).getCellRangeByName(do_adr).CellAddress
ThisComponent.Sheets.getByName(do_ark).CopyRange(cel,zrodlo)
end sub

Funkcja pobiera numer z komórki

Kod: Zaznacz cały

Function wezn (ark as string, gdzie as string) as double
rem funkcja pobiera wartość ze wskazanego miejsca
rem ark= nazwa arkusza
rem gdzie= nazwa komórki jako np b12
wezn = ThisComponent.Sheets.getByName(ark).getCellRangeByName(gdzie).getValue
End Function

[Rafkus]

Ale w parametrach "Narzędzia -> Współużytkuj arkusz kalkulacyjny..." można ustawić możliwość równoległej pracy wielu użytkowników na tym samym arkuszu. Przy czym "tym samym" oznacza pracę na kopii pobranego arkusza. Opis jak to funkcjonuje można przeczytać wywołując przycisk "Pomoc" w oknie dialogowym otwartym wyżej wspomnianym poleceniem.

Tak z ciekawości zainteresowałem się tym tematem, przeczytałem tekst pomocy:
https://help.libreoffice.org/3.3/Common ... gramu_Calc
Następnie poeksperymentowałem (sumarycznie całą sobotę - pogoda nie dopisala i trochę niedzieli) i doszedłem do pewnych wniosków – jak ulepszyć plik rejestr aby działał poprawnie w trybie współużytkowania:
- podczas współdzielenia nie ma możliwości sterowania ochroną arkusza z poziomu programu (opcja została wyszarzona) ale na szczęście działa z poziomu makra;
- plik musi się aktualizować w przypadku wywołania okna dialogowego i oczywiście po jego zamknięciu oraz tuż przed przekazaniem danych z formularza do arkusza;
- podczas testów odkryłem, że trzeba nieco spowolnić proces zapisu, zdarzało się czasami, że dane do arkusza były wstawiane gdy ochrona jeszcze działała albo już działała. Spowolnienie uzyskałem stosując polecenie wait 1000 (zatrzymaj się na 1 sekundę) przed i po zapisie;
- Jako że współdzielenie „oznacza pracę na kopii pobranego arkusza” zmieniłem moment wylogowania użytkownika, makro Wyloguj przypisałem do zdarzenia otwórz dokument.

Niestety znalazłem również dwa problemy.
Pracowałem na trzech kopiach tegoż pliku jednocześnie (w OO, LO pozwalał na otwarcie tylko 1 okna), współużytkowanie działało dobrze.

Pierwszy problemik rozpoczyna się gdy jeden z użytkowników zakończył pracę, dostał monit czy chce zapisać wprowadzone dane. W przypadku wybrania opcji ZAPISZ – jeżeli inni użytkownicy wprowadzili już jakieś dane, – może otrzymać całkiem pokaźną liczbę informacji o niemożliwości aktualizacji danych. Te komunikaty wystąpią dlatego, że arkusz ma włączoną ochronę. Dlatego ZALECAM wybieranie opcji NIE ZAPISUJ, jak pisałem wyżej o aktualizację(zapis) dba moje makro.

Drugi problem. Jeden z użytkowników wyłączył swój plik, chwilę później inny użytkownik chce wprowadzić nowe dane, uruchamia makro i … otrzymuje komunikat, że ten plik nie jest już współużytkowany (Zgroza, - występuje tylko w OO, LO nie stwarzał problemu ). ROZWIĄZANIE jest proste: niech również wyłączy plik i uruchomi go ponownie.

[andro]

Fajnie, że podejmujesz dalej temat. Wieczorkiem przejrzę go, a jutro sprawdzę, jak to się ma w realu.

pozdrawiam

[Jermor]

Muszę wam koledzy powiedzieć, że nadal inaczej widzę rozwiązanie problemu @andro.
To na czym zależy @andro, to możliwość, aby wiele osób mogło uzupełniać rejestr zdarzeń. Przy czym osoby te mogą pracować równocześnie na kilku stanowiskach.
W tej sytuacji uważam, że rejestr zdarzeń powinie być oddzielnym plikiem bez żadnych makr, zapisanym na serwerze plików pod jakąś nazwą np. rejestr.ods,.
Niezależnie od tego istnieje plik o nazwie np. rejestrator.ods. Plik ten zawiera makra i może zostać powielony na każdym stanowisku, na którym przewiduje się wprowadzanie danych do rejestru.
Działanie makr w pliku rejestrator.ods.

1. Weryfikacja użytkownika, mniej więcej tak jak to zaproponował @Rafkus. Zmieniłbym tytuł okna dialogowego z „REJESTR” na „REJESTR: niezalogowany” a po zalogowaniu na „REJESTR: nazwa użytkownika”.
2. Po wprowadzeniu danych procedura zapisywania przenosi dane do kolejnego wiersza w pliku rejestrator.ods., uzupełniając go o dane sygnatury czasu i użytkownika. Użytkownik może wprowadzać wiele rekordów danych. Zakładam, że plik rejestr.ods będzie aktualizowany dopiero przy kończeniu pracy z plikiem rejestrator.ods.
3. Przy kończeniu procesu rejestrowania wywołana jest procedura, która ładuje plik rejestr.ods, jako drugi dokument. Jeżeli plik ten jest aktualnie otwarty przez innego użytkownika, pojawia się błąd. Przy pomocy instrukcji typu ON ERROR można go obsłużyć, (np. kilkukrotnie ponowić próbę ładowania, a gdy się nie powiedzie zapisać i zamknąć plik z wprowadzonymi rekordami).
   Po załadowaniu pliku rejestr.ods makro przenosi wszystkie rekordy zapisane w pliku rejestrator.ods do pliku rejestr.ods, zapisuje go i zamyka. Po zapisaniu rejestru usuwa rekordy znajdujące się w rejestrator.ods. Zapisuje i zamyka plik.

Potencjalne trudności. Rozproszone pliki rejestrator.ods są trudne do aktualizacji pod kątem dodawania nowych użytkowników i zmiany haseł wtedy, gdy nazwy użytkowników i hasła są zakodowane bezpośrednio w Basicu.
Jeśli nazwy użytkowników i hasła miałyby być pobierane z zewnętrznego pliku, istnieje możliwość podglądu tych danych przez niepowołane osoby. Należałoby zatem hasła zapisywać jako tekst zaszyfrowany i wprowadzane hasło szyfrować i porównać z wersją zapisaną w pliku.
Basic, o ile wiem, nie ma funkcji szyfrującej, takiej jak np. SHA1 lub MD5 w PHP. Można jednak zbudować sobie samodzielnie taką funkcję. Zakładając, że nie chodzi o klasę tajności top secret, może to być algorytm tylko utrudniający odkodowanie hasła. Np. bierzemy liczby pierwsze 1, 3, 7 i zakładamy, że hasło może składać się z nie więcej niż 8 znaków. Tworzymy sumę iloczynów liczb pierwszych i kodu dziesiętnego kolejnego znaku. Liczby pierwsze są wykorzystywane cyklicznie. Taką sumę zapisujemy w bazie haseł. Sama funkcja może wyglądać mniej więcej tak:

Kod: Zaznacz cały

Sub Main
Haslo="A.e\r"
Wery=0
for i=1 to len(haslo)
if i mod 3 = 0 then wery=wery + asc(mid(haslo,i,1))
if i mod 3 = 1 then  wery=wery + asc(mid(haslo,i,1))*3
if i mod 3 = 2 then wery=wery + asc(mid(haslo,i,1))*7
next
print wery
End Sub

Dla wpisanego hasła wynikiem jest liczba 1692 i tę właśnie liczbę wpisujemy do pliku z hasłami. Gdy użytkownik poda hasło, funkcja wylicza liczbę i następnie sprawdza, czy ten użytkownik ma tę właśnie liczbę zapisaną w bazie haseł.
Ponieważ biblioteka jest chroniona hasłem, osoby nieupoważnione nie powinny poznać algorytmu obliczeniowego.

Teraz, dlaczego sądzę, że współużytkowanie nie spełni oczekiwanej roli? Napisał o tym @Rafkus, cytując help. Użytkownicy pracują na kopiach oryginalnego dokumentu. Niech będzie ich dwóch, A i B. Obaj otworzyli rejestr i mają pierwszy dostępny wiersz do zapisu np. 100. Użytkownik A dopisał u siebie wiersz i wykonał zapis rejestru na dysku. Ponieważ nikt nie dokonał żadnych zmian w pliku, zapisana została wersja użytkownika A. Teraz ma on dostępny 101 wiersz do zapisu. W tym czasie użytkownik B także dopisał swoje dane w setnym wierszu i zapisuje plik na dysku. System stwierdza, że w wierszu 100 są już jakieś dane, inne niż te, które w tym miejscu były, gdy plik był otwierany. W związku z tym należy rozwiązać problem, które z nich mają zostać zapamiętane. Jeśli użytkownika B, to dane użytkownika A zostaną stracone, jeśli użytkownika A, to dane użytkownika B zostaną stracone. Musimy pamiętać o tym, że system odświeża dane tylko temu użytkownikowi, który dokonał zapisu. Inni nic nie wiedzą o tym, że w pliku nastąpiły zmiany i dowiedzą się o tym dopiero podczas zapisywania swojej pracy i to tylko wtedy gdy nastąpi konieczność rozwiązania konfliktu. W przypadku problemu @andro, każda operacja dopisywania do rejestru wykonywana równolegle przez kilku użytkowników prowadzi do konieczności rozwiązania konfliktów. Dopóki konflikt nie zostanie rozwiązany, żaden inny użytkownik nie ma dostępu do pliku. Może więc być tak, że po rozwiązaniu konfliktu między A i B należy rozwiązać kolejny dotyczący użytkownika C.

To takie mam uwagi na ten temat.

[Rafkus]

Co do punktu 1 @Jermor masz rację, lepiej będzie Nazwę użytkownika wciągnąć do tytułu okna dialogowego. Wystarczy w dwóch miejscach zamienić linijkę kodu:

Kod: Zaznacz cały

Dlg.GetControl("CommandButton6").Model.label = "Użytkownik: "& ktos
na tą:
Dlg.Model.Title = "REJESTR: "&  ktos    'zmiana nazwy okna dialogowego    

Co do osobnego pliku rejestru, to nie mam na niego pomysłu, więc nawet nie próbuję to zrealizować.

Co do działania makra, pracuje on według schematu:

• 1. Uruchomienie okna = uruchomienie zapisu czyli aktualizacja danych
  2. opcjonalnie logowanie
  3. wpisywanie danych do formularza
  4. po wypełnieniu poprawnie formularza następuje zapis arkusza (aktualizacja danych)
  5. do pierwszego wolnego wiersza są wstawiane dane z formularza
  6. i znowu następuje zapis (aktualizacja)

Tak więc bardziej mnie zastanawia jakie jest prawdopodobieństwo, że Użytkownicy A i B będą chcieli wprowadzić dane dokładnie w tym samym momencie.
Może to nieco naciągane, ale można by ustawić tak, żeby punkt 4 dla użytkownika 1 odbywał się zawsze przy pełnej minucie, dla użytkownika 2: 5 sekund po pełnej minucie, itd...
---------------------------------------
Edit: Drugi pomysł
W arkuszu zrobić tabelę zgłoszeń czyli miejsce w którym będzie zapisany znacznik czasu: data i godzina w chwili poprawnego wpisania danych do formularza. Funkcja Min będzie szukać najwcześniejsze zgłoszenie w tym zakresie, a funkcja PODAJ.POZYCJĘ powie na której pozycji się ona znajduje (pozycja = użytkownik). Jak to ma działać:

• Punkty 1,2,3 bez zmiany
  4a. po wypełnieniu poprawnie formularza następuje zgłoszenie chęci zapisu do tabeli zgłoszeń. Każdy użytkownik ma przydzieloną konkretną, inną komórkę więc nie będzie problemu z zapisem
  4b. (można dać chwilę pauzy i ponowne zapisanie - sprawdzenie czy ktoś jeszcze nie nie zgłosił się w tym samym czasie)
  4c. odczytanie kto zgłosił się najwcześniej
  4d. jeżeli nie ja: chwila przerwy, ponowny zapis i znowu punkt 4c.
  Jeżeli ja zgłosiłem się najwcześniej
  5. do pierwszego wolnego wiersza są wstawiane dane z formularza, czyszczę swoją kontrolkę w tabeli zgłoszeń
  6. i znowu następuje zapis (aktualizacja)

[Jermor]

Chyba obaj @Rafkus'ie nakręciliśmy się na ten problem, który @andro już dawno oznaczył jako rozwiązany. Ale oto moje wyjaśnienia.
Plik rejestr.ods zawiera od pewnego wiersza wpisy dodawane przez innych użytkowników. W pierwszych wierszach mogą znajdować się jakieś informacje opisowe. Plik zapisany jest na serwerze i dostępny dla innych użytkowników.
Użytkownicy mają do dyspozycji kopie pliku rejestrator.ods przy pomocy którego tworzą nowe rekordy danych. Czy to będzie dialog, czy wypełnianie wprost wierszy, nie ma znaczenia.
Dane w tym pliku są zawsze umieszczane po ostatnim zajętym wierszu. Samo zapisanie (przeniesienie) tych danych do rejestru odbywa się na żądanie użytkownika. Przebiega ono następująco:
Otwierany jest równolegle plik rejestr.ods. Jeśli plik ten jest aktualnie otwarty przez innego użytkownika, pojawia się komunikat informujący o tym i wymagający podjęcia decyzji: Anuluj, Otwórz tylko do odczytu, Otwórz jako kopię. W każdym z tych przypadków makro zaniecha otwarcia i ponowi próbę po 2 sekundach. Jeśli użytkownik wybrał inną opcje niż Anuluj otwarta zostanie wybrana instancja pliku, lecz makro zaraz ją zamknie i spróbuje ponownie otworzyć plik. Po określonej liczbie takich prób, makro się zatrzyma. Żadne zgromadzone dane w rejestratorze nie zostaną stracone.
Jeżeli plik został otwarty, makro wyznacza ostatni wiersz w rejestrze, po którym można zapisywać dane. Ostatni wiersz danych zgromadzonych w rejestratorze, i w odpowiednich pętlach kopiuje te dane do rejestru.
Po przeniesieniu danych plik rejestru jest zapisywany i zamykany. Od tego momentu jest dostępny dla innego użytkownika.
Makro, które to realizuje trochę niechlujnie napisane) jest takie:

Kod: Zaznacz cały

Sub Main
GlobalScope.BasicLibraries.LoadLibrary("Tools")
nl=chr(13)
oDoc1=ThisComponent
NazwaPliku = "Z:\Forum oo\bd.ods"
oSheet1=oDoc1.Sheets.getByName("Arkusz1")
otwarte=false
dostep=0   'licznik prób dostępu do rejestru.
dostepmax=5	' maksymalna liczba prób.

Do While not(otwarte)
oDoc2=StarDesktop.loadComponentFromURL(ConvertToURL(NazwaPliku), "_blank", 0, dimArray())
otwarte=true
' If obsługuje sytuację gdy plik rejestr jest już otwarty i pojawi się komunikat
' jak użytkownik chce postąpić
If IsNull(oDoc2) then 
otwarte=false : Wait 2000	'Wybrano Anuluj
elseIf Instr(oDoc2.Title,"(tylko do odczytu)")>0 or InStr(oDoc2.Title,"Bez tytułu")>0 then 
otwarte=false	'wybrano otwórz kopię albo tylko do odczytu
oDoc2.close(true)	'zamknięcie tak otwartego pliku
Wait 2000
End If
dostep=dostep+1
If dostep>dostepmax then
MsgBox "Limit prób (" & dostep & ") został osiągnięty." & nl & _
 "Dane zostaną zapamiętane do następnego uruchomienia",0,"Rejestr" : Stop
End If
loop
'Tutaj możesz pracowac na dwóch roznych plikach.
oSheet2=oDoc2.Sheets.getByName("Arkusz1")

kopiujdo=getlastusedrow(oSheet2)	'ostatni wiersz w rejestrze
ostatniz=getlastusedrow(osheet1)	'liczba wierszy w rejestratorze.
For i= 1 to ostatniz
for j=0 to 2	' kolumny do skopiowania
oSheet2.getCellByPosition(j,kopiujdo+i).string=oSheet1.getCellByPosition(j,i).getstring
next j
next i
oDoc2.store() ' ta instrukcja zapisuje plik bazy
oDoc2.close(true) ' ta instrukcja zamyka plik
stop
End Sub

Osobiście po takim zapisie dodałbym jeszcze usuwanie danych gromadzonych w rejestratorze (aby nie zostały niechcący po raz drugi dopisane) i zapisanie samego pliku rejestratora.

[andro]

Wczoraj zupełnie nie miałem czasu, aby tu zajrzeć. Złapałem się na tym, że mimo wszystko Forum to uzależnia .
Moje oznaczenie [Solved] wynikało raczej z faktu, że trochę zacząłem się krępować, że być może nadużywam waszego czasu, przedłużając tą wymianę postów.
Nie oznacza to, że nie jestem wdzięczny, że dalej rozwijacie ten projekt. Bardzo mnie to cieszy. Na marginesie, patrząc na to, co tu się tworzy, to raczej problem tak do końca nie prędko będzie rozwiązany
A teraz do rzeczy. Zrobiłem szybko (mało czasu) eksperyment na Twoim @Rafkus ostatnim pliku, dotyczącym współdzielenia.
Otóż w praktyce nie do końca to działa. Być może nie zrozumiałem dobrze wszystkich Twoich sugestii.
Test polegał na tym, że jeden użytkownik wszedł do Rejestru i go blokuje, drugi próbuje dopisać w tym czasie swój rekord.
Po wybraniu opcji Wybranie opcji Otwórz kopię – otrzymuję komunikat o włączeniu makr i przechodzę do Rejestru. Po wybraniu przycisku Formularz, wyświetla się okno z sugestią zapisu kopii lub anulowaniu.
Wybranie Anuluj, przechodzę do panelu logowania. Po zalogowaniu wypełniam formularz. Przy próbie zapisu, wyświetla się ponownie okno zapisu kopii Rejestru w określonej, nowej lokalizacji (tak, jak poprzednio). Wybranie anuluj,powoduje powrót do Rejestru z wypełnionym rekordem, który de facto niw jest zapisany. I tak w kółko. Nie ma możliwości w takiej sytuacji zapisać rekord, dopóki użytkownik blokujący nie wyjdzie z Rejestru.

[andro]

Teraz w całości przeczytałem Wasze posty. Trochę dziwnie wyglądają te moje wywody prowadzone z takim opóźnieniem, kiedy dyskusja poszła już dalej.
W praktyce, o czym wspominasz @Rafkus, niestety zdarzać się będzie, że użytkownicy chcą dokonać wpisów jednocześnie. Użytkownicy są rozproszeni po odległych placówkach więc krzyknięcie przez biurko "ja teraz wpisuję" odpada.
Też rozważałem postawienie jakiegoś serwera, a może Firebird?
Jak nie da się rozwiązać tego problemu, trzeba będzie żyć, jak dotychczas, czyli ćwiczyć cierpliwość podczas czekania na zwolnienie Rejestru..

[Rafkus]

...Po wybraniu opcji Wybranie opcji Otwórz kopię – otrzymuję ...

To świadczy o tym, że plik nie miał włączonej opcji współdzielenia.
Niech wszyscy wyłączą swoje kopie tego piku, następnie jedna osoba go uruchomi. Na pasku menu kliknie Narzędzia ---> Współużytkuj dokument. W wywołanym oknie zaznaczy pole wyboru "Współużytkuj ten arkusz a innymi osobami" i potwierdzi - kliknąć OK. Teraz powinieneś otrzymać monit że arkusz musi zostać zapisany aby był współdzielony - kliknij tak.
Od teraz inni użytkownicy mogą go (mam nadzieję) bez problemu używać, podczas uruchamiania mogą jedynie otrzymywać monit, że plik pracuje w trybie dzielonym.

Czemu nie podesłałem pliku z włączoną opcją współużytkowania - bo poprawiałem makro, a zauważyłem, że jak się je poprawia w włączonym trybie to jest ono nadpisywane tylko na lokalnej kopi. Po ponownym uruchomieniu zmienione elementy w najlepszym przypadku wracały do stanu początkowego (raz "zgubił się" formularz, za drugim razem cała biblioteka )
-----------------------------------
Edit:
@Jermor
Przetestowałem makro @Jermor, całkiem zgrabnie to wyszło. Dzięki niemu współdzielenie osiągnięte zostało w inny sposób, w zasadzie to współzapis. Dla tego matkra zaprojektowałbym nie okno dialogowe, ale formularz taki z BASE (zapisany jako osobny plik) i zsynchronizował poszczególne pola z miejscami zapisu w CALCU.

[andro]

Oczywiście, że działa. Zupełnie o tej opcji zapomniałem.
W dniu dzisiejszym test przebiegł w zasadzie bez problemów.
Jeden użytkownik wchodzi i blokuje tym samym Rejestr. Drugi otwiera Rejestr, dopisuje swój rekord i przy próbie zapisu otrzymuje komunikat o istniejącym konflikcie pomiędzy użytkownikami, po czym wybranie opcji "zachowaj wszystkie obce" Rejestr zostaje zaktualizowany o obcy wpis. Ja zapisuję swój rekord i jest OK.
Druga próba odbyła się już bez owego komunikatu o konflikcie. Oczywiście oprócz poprawnego komunikatu o aktualizacji rekordów, w momencie, gdy podczas zapisu rekordu "wisi" obcy wpis.
Tak sobie myślę, że powodem owego komunikatu o konflikcie, może być próba dopisania do Rejestru rekordów poza formularzem. W tym momencie ochrona była właśnie wyłączona.
Jednak następna próba pokazała, że nie miało to prawdopodobnie związku, a co najważniejsze ochrona była wyłączna w odpowiednim momencie.
Ciekawi mnie, czy pokusicie się o "rzeźbienie" dalej tego projektu...Byłoby fajnie. Wspominasz @Rafkus o Base. Czy to oznaczać może, że taką funkcjonalność (myślę chociażby o współużytkowaniu czy nadawaniu analogicznych, jak tu uprawnień dla użytkowników) można tam osiągnąć?

[Rafkus]

przy próbie zapisu otrzymuje komunikat o istniejącym konflikcie pomiędzy użytkownikami,

A więc jednak można trafić w moment że danych w danym w jakimś wierszu niby jeszcze nie ma, a jednak już są. W wolnych chwilkach będę rzeźbił temat dalej. Jest ciekawy, bawię się w programowaniem, widzę efekty i jestem zadowolony.

Co do base to właśnie prowizorycznie przetestowałem wysłanie wartości z jakiegoś jednego pola mojej testowej bazy do pliku rejestru calca przy pomocy makra @Jermora i ... dało radę. Cierpliwości, jak znajdę czas i będzie to w nieco lepszym stanie to przedstawię wynik.
Powtarzam, myślałem o użyciu FORMULARZA Z BASE, a nie base. Na każdym stanowisku zostanie zainstalowana kopia tegoż pliku, a w chwili wywołania zapisu zostanie wykorzystane makro @Jermora: (otwarcie pliku calca, wstawione dane z formularza, zapisanie calca i jego zamknięcie).

[andro]

Wszystko jasne.
Dlaczego zapytałem właśnie o Base?
Otóż do tej pory korzystam z tego rodzaju Rejestrów. Dwa lata temu to zrobiłem i tak ciągnę. Generalnie są problemy z wielodostępem, ale to normalne (oczywiście bez makr) oraz jakiś problem się przyplątał. dając komunikat
"nie udało się połączyć ze źródłem danych "Centralny Rejestr"
General error: org.hsqldb.lib.FileSystemRuntimeException:java.io.IOException"
Wyszło na to, że blokował użytkownik, który otworzył Rejestr, zamknął go, a miał w tle jakiś proces lub nieaktualną librę. Następny użytkownik przy próbie wejścia do Rejestru otrzymywał właśnie taki komunikat.
Problem zniknął (mam nadzieję, że na stałe), po aktualizacji libry, no i może jeszcze coś Panowie z IT zrobili, nie wiem.
Ale to tak na marginesie.
Co do naszego projektu, to oczywiście spokojnie będę czekał....

[Jermor]

Własnie o tym cały czas wam piszę. Współdziałanie plików nie jest dobrym rozwiązaniem. Ten sam plik jest otwarty równocześnie w kilku lokalizacjach. Kiedy ktoś zapisuje swoją wersję pliku, nadpisuje tylko swoje dane, w komórkach, które sam zmienił. Komunikaty wynikają z działań innych użytkowników.
Załóżmy, że równolegle pracuje trzech klientów A, B i C, otworzyli współdzielony plik.
Klient A zmienił zawartość komórki B2, klient B komórki C3 a klient C - komórki D12 każdy na swoim komputerze.
Jako pierwszy swoje dane zapisuje klient A. Dzieje się to bez żadnego komunikatu. Jego dane zostają zapisane i plik zostaje ponownie wczytany. "A" widzi to, co było, tylko ze zmienioną zawartością B2. Teraz swój plik zapisuje klient B. Plik zostaje zapisany i pojawia się komunikat, że wczytany przez niego plik miał zmiany wprowadzone przez innego użytkownika. Komórka B2 w pliku jest objęta ramką, wskazującą jakie dane, oprócz zapisanych przez "B" w C3, zostały zmienione. Po naprowadzeniu wskaźnika myszki na tę ramkę, pojawi się "dymek" z informacją kto, co zmienił i na co. Teraz dane zapisuje "C" on także dostaje komunikat o zmienionych danych, tylko, że u niego ramką są objęte komórki B2 (zmieniona przez "A") i C3 (zmieniona przez "B").
Teraz "A" ponownie zmienia zawartość B2, przy zapisaniu dostaje informacje o zmienionych C3 i D12. O tej zmianie nie wiedzą ani "B" ani "C". Niech teraz "B" też zmieni zawartość B2 i spróbuje to zapisać. Dostanie komunikat o konflikcie informujący o tym, że inny użytkownik (w tym przypadku "A") zmienił już zawartość B2, więc należy odpowiedzieć, która z wartości ma zostać zachowana.
Co to oznacza w praktyce?
Wszyscy użytkownicy wczytują stan pliku taki, jaki jest aktualnie zapisany na dysku. Np. gdy plik wczytywał "A" pierwszym dostępnym wierszem był 10. Zatem wszystkie dane ten użytkownik umieści w komórkach od A10:F10. Jednak w tym czasie użytkownik "B" też otworzył plik. On też ma dostępny jako pierwszy wiersz 10. Zatem swoje dane także umieści w komórkach A10:F10. Gdy "A" zapisze plik pierwszym wolnym wierszem będzie już 11. Ale "B" nic o tym nie wie, i próbuje zapisać swoje dane. Otrzymuje zatem komunikat, że te komórki są już nadpisane przez innego użytkownika. Należy zatem podjąć decyzję czyje dane są właściwe. Jeśli odpowiemy, że "B" to dane zostaną nadpisane a o tych zmianach "A" dowie się dopiero, gdy będzie zapisywał następne swoje dane . Gdy odpowiemy, że dane "A", to "B" otrzyma plik z dostępnym pierwszym wierszem 11 i musi je ponownie wprowadzić. Jeśli będzie to robił powoli i niezdarnie, to może zdarzyć się, że "A" albo "C" zdążą dopisać następne dane i znowu pojawi się konflikt.
To dlatego uważam, że moje rozwiązanie jest właściwe. Plik jest przejmowany tylko na dopisanie danych, po czym zamykany i dostępny każdemu, który go potrzebuje. Jeśli użytkownik zechce otworzyć plik właśnie przez kogoś modyfikowany, będzie musiał poczekać na zakończenie akcji zainicjowanej przez tego użytkownika.

[Jermor]

Koledzy, przedstawiam wam moją propozycję.
Założenia:
Na serwerze plików dostępnym dla użytkowników zapisany jest plik o nazwie „rejestr.ods”
W określonym arkuszu tego pliku, po ostatnim zajętym wierszu, mają być dopisywane kolejne dane.
Ponadto na serwerze znajduje się drugi plik o nazwie „hsl.txt” zawierający wierszami wpisane nazwy użytkowników zakończone przecinkiem a po spacji, obliczonym numerem kontrolnym hasła.
Użytkownicy korzystają z pliku o nazwie „rejestrator.ods”, którego zadaniem jest zarejestrowanie wymaganych wpisów. Rejestrowane dane umieszczane są w pliku „rejestrator.ods”, poczynając od drugiego wiersza, a następnie na żądanie użytkownika, przeniesione do pliku „rejestr.ods”.
Po uruchomieniu pliku „rejestrator.ods” uruchamia się makro „logowanie”.
Prosi ono użytkownika o podanie loginu, czyli nazwy użytkownika, a następnie hasła. W makrze można ustawić zmienną określająca minimalna długość hasła (zmienna ihslmin, obecnie ustawiona na 5). Makro otwiera i czyta plik „hsl.txt” sprawdzając, czy taki użytkownik jest na liście. Jeśli jest, Konwertuje podane przez niego hasło na kod numeryczny i porównuje z kodem zapisanym w pliku „hsl.txt”. Jeśli kody są zgodne, użytkownik jest legalny. W pozostałych przypadkach użytkownik jest odrzucany. Uwaga! W nazwie użytkownika wielkość liter odgrywa rolę.
Proces tworzenia wpisów został już zrealizowany w innym przebiegu.
Ostatnim przebiegiem jest zapisanie danych zgromadzonych w rejestratorze w pliku rejestru. Opisałem ten proces we wcześniejszym poście. Załączone makro kopiuje trzy kolumny danych.
Makra zawierają ponadto funkcję „Weryfikacja”, która oblicza kod hasła na podstawie jego znaków.
Makro kodyhasel przydatne administratorowi, do wyznaczenia kodu numerycznego hasła.

Administrator musi utworzyć zwykły plik txt zawierający dane do logowania, np. wyglądające tak:
Romek, 1514
Tomek, 1614
Ewa, 2049
To są zapisy kodów odpowiadające następującym hasłom: x.23R7 a@@34BL oraz wzRy12

Nie tworzyłem w pliku żadnych przycisków, bo powiązanie tych procedur pozostawiam temu, kto będzie używał wersji ostatecznej.
Ponadto należy zmienić dane o położeniu plików.

[andro]

Odnosząc się do Twojego @Jermor postu, to faktycznie masz rację. Może się zdarzyć, że przy pracy kilku użytkowników jednocześnie, finalnie mogą się znaleźć nie wszystkie rekordy, bowiem w przypadku konfliktu, użytkownik ma do wyboru zapisanie swoich danych, albo obcych. Nigdy wszystkich. Chociaż przy wczorajszym teście taki przypadek zaistniał, wybrałem więc zapis obcych, a potem swobodnie zapisałem swój rekord. Jednak co by się stało, gdybym wybrał odwrotnie.... ?, nie wiem.
Z kolei odnosząc się do ostatniego postu, rozumiem, że mimo wszystko jednoczesna praca na pliku nie jest możliwa. Pełna autoryzacja dostępu użytkownika i logi tak, jednak musi on, aby wejść do Rejestru blokowanego przez innego użytkownika, czekać.... ?

[Jermor]

Moje rozwiązanie zakłada(ale nie jest wdrożone w załączonym pliku, on zawiera tylko niezbędne moduły), że :
Istnieje podstawowy plik rejestr, zawierający wpisy wprowadzane przez użytkowników przy pomocy pliku rejestrator.
Użytkownik otwiera plik rejestrator. Rejestrator zapisuje wyłącznie dane wprowadzane przez użytkownika, który go otworzył. Plik po załadowaniu automatycznie uruchamia procedurę logowania. Jeśli procedura odrzuci logowanie, plik zostanie automatycznie zamknięty. Jeśli procedura jest pomyślna dla użytkownika, uruchamiany jest moduł wprowadzania danych. np. ten zaproponowany przez @Rafkus'a realizowany przy pomocy okna dialogowego.
Dane wprowadzane przez ten moduł są zapisywane w wierszu po ostatnim wpisie znajdującym się w rejestratorze. Czyli albo od wiersza nr 2 (jeżeli rejestrator zakończył poprzednia sesję zapisaniem swoich danych w rejestrze) albo po ostatnim zapisanym wierszu, który ciągle znajduje się w rejestratorze (czyli wtedy gdy zapisanie danych do rejestru się nie powiodło).
Gdy użytkownik zakończy swoją pracę uruchamiany jest (automatycznie albo na żądanie) moduł przeniesienia zgromadzonych wierszy w rejestratorze do rejestru właściwego. Gdy ten proces zakończy się pomyślnie plik rejestru zostanie zapisany i zamknięty. Ponadto zgromadzone w rejestratorze dane zostają usunięte i plik rejestratora także zostanie zapisany i zamknięty. Gdy przeniesienie danych się nie powiedzie (np. przekroczono liczbę prób dostępu do pliku rejestr) rejestrator zapisze swój stan, czyli zachowa zgromadzone dane. Mogą one być dopisane do rejestru później.
Co dalej? To znaczy, czy zamknąć rejestrator, czy go pozostawić otwartym i ewentualnie dopisywać następne dane, albo po prostu spróbować ponownie zaktualizowania rejestru, to pozostaje do twojej decyzji.
Plik rejestru jest "zawłaszczany" przez rejestrator tylko na czas przeniesienia danych z rejestratora do rejestru. Po tej operacji jest zwalniany i dostępny dla innego użytkownika. Ta operacja nie powinna trwać długo (oczywiście zależy to w jakimś stopniu od liczby wierszy, które mają być przeniesione, od przepustowości sieci) dlatego wykonywanych jest kilka prób zapisu z przesunięciem czasowym. Dopisywane dane nie będą powodowały konfliktu, bo zawsze zostaną dopisane w rejestrze po ostatnim wierszu.
Równoczesna praca na pliku rejestru polega zatem na tym, że wielu użytkowników może w dowolnym momencie na chwilę otworzyć plik, dopisać jakieś dane i go zamknąć.

[Rafkus]

Pierwsza wersja formularza, wykorzystujący pierwszy kod @Jermora

[andro]

Zapowiada się bardzo dobrze.

[Rafkus]

W wolnych chwilach pracowałem nad tym projektem, Przedstawię nową wersję -3.

Odnośnie wykonania poprzedniej wersji: wykonałem go przy pomocy BASE. Otworzyłem jakiś byle jaki plik bazy, otworzyłem plik rejestru, zaznaczyłem interesujący w nim fragment danych i przeciągnąłem go do bazy - utworzyła się tam nowa tabela. Przy pomocy kreatora stworzyłem formularz. W otwartym formularzu wybrałem zapisz kopie jako ... i w ten sposób uzyskałem samodzielny formularz.

Założenia:
Na serwerze plików dostępnym dla użytkowników zapisany jest plik o nazwie „rejestr.ods”
W określonym arkuszu tego pliku, po ostatnim zajętym wierszu, mają być dopisywane kolejne dane.
Ponadto na serwerze znajduje się drugi plik o nazwie „hsl.txt” zawierający wierszami wpisane nazwy użytkowników zakończone przecinkiem a po spacji, obliczonym numerem kontrolnym hasła.

Spodobał mi się pomysł @Jermora odnośnie zapisu danych w dokumencie w przypadku braku połączenia z Rejestrem, spróbowałem więc taki formularz zrobić w Calcu (to była 2 wersja), ale efekt był raczej marny więc go porzuciłem.
Zamiast tego Kombinowałem więc z poprzednią wersją. Dodałem w nim sekcję(którą można ukrywać) i w niej zrobiłem tabelę do przechowywania danych.Teraz dane z pól formularza są wstawiane do Tabeli1 z Sekcji1 a z niej do rejestru.
Żeby nie trzeba było grzebać przy makrze z każdym nowym użytkownikiem znowu wykorzystałem opcję @Jermora na przechowywanie Aliasów i haseł w zewnętrznym pliku tekstowym. (Ale jeśli chcesz, to dane te możesz dalej wpisywać do makra) Podczas testów wyszło, żeby w pliku tekstowym w nazwach użytkowników, lepiej nie wstawiać polskich znaków, zamiast nich pojawiały się jakieś ?chińskie znaki, a podczas szyfrowania następował błąd przepełnienia danych.
Wymyśliłem, aby ścieżki do pików: Rejestru i Użytkowników przechowywać we Właściwościach Użytkownika (z menu Plik kliknij Właściwości i wybierz kartę Właściwości Użytkownika), w ten sposób nie trzeba będzie grzebać niepotrzebnie w makrze.
Edycja ostatniego rekordu i usunięcie ostatniego rekordu jest nie skończona (działa tylko w formularzu, gdy jest problem z plikiem rejestru).

PS. Tak się zastanawiam czy tego wątku nie przenieść do działu projektów, a nazwę tego wątku zmienić na np. Wspólne użytkowanie Calca.

[andro]

Witam,
Widzę, że projekt ma się dobrze…. No właśnie, a propos tego z czym mamy tu do czynienia.... Myślę, że to nie jest zwykła pomoc, z jaką ma się zwykle styczność na forum i zakończenie postu, ale jest to rozwijający się właśnie projekt i należałoby dać należne mu miejsce . Tak więc spokojnie możesz to wszystko przenieść pod nazwą np. „calc – współdzielenie pliku”, czy coś podobnego.
Patrząc na sam formularz, widzę, że przybywa tu coraz więcej ciekawych funkcjonalności.
Rozumiem, że tabela w górnej części formularza pokazuje wszystkie rekordy, które są wprowadzone przez użytkowników, jednak nie dodane do Rejestru ze względu na jego zajętość. Po zakończeniu wpisywania i zamknięcia Rejestru przez użytkownika, który blokował Rejestr, rekordy znajdujące się w powyższej tabeli zostaną dodane do Rejestru wg kolejności wpisywania. Czyli mamy tu do czynienia z tworzeniem coś w rodzaju pliku tymczasowego .tmp. Nie wiem, czy to dobrze zrozumiałem.
Co do logowania, czy nie lepszym rozwiązaniem byłoby wymuszenie na użytkowniku wykonanie jako pierwszej, czynności logowania?
W obecnej chwili użytkownik niezalogowany może wypełnić formularz. Oczywiście nie zapisze go, ponieważ dostaje komunikat: „Plik z danymi użytkowników nie jest dostępny”, po czym wyświetla się okno logowania.
Podobnie ma się rzecz z edytowaniem, wyczyszczeniem, czy w końcu usunięciem rekordów z tabeli w formularzu (nawet innego użytkownika). To można wykonać będąc niezalogowanym. Oczywiście jest to, jak piszesz w trakcie prac.
Co do miejsca przechowywania loginów i haseł. Bardzo dobry pomysł daje @Jermor. Zawsze łatwiej, a przede wszystkim bezpieczniej nie grzebać bez potrzeby w makrach.
Zastanawiam się tylko nad kwestią zabezpieczenia tych plików, przy znajomości przez użytkowników ścieżek. Jeżeli hasła i loginy byłyby w makrze i zawarte w dodatku w bibliotece innej, niż standard, to byłoby to za jednym pociągnięciem hasła wszystko chronione.
No, ale oczywiście na wszystko jest rozwiązanie.

Przypomniało mi się, więc dopisuję.Czy dopisywane rekordy mogą być numerowane automatycznie? Kwestia numeracji jest ważną rzeczą w Rejestrze. Otóż ma on nie tylko za zadanie zapisać rekord, ale również nadać kolejny numer użytkownikowi, który wykorzysta go w innym miejscu. Tak więc użytkownik zapisując rekord i wychodząc z Rejestru winien już znać pod jaką pozycją dokonał zapisu. Chodzi mi tu o kwestię zajętości pliku i faktycznej kolejności dodawania rekordu do Rejestru, po jego zwolnieniu się. W obecnym Rejestrze (Base) użytkownicy wykorzystują klucz główny, jako kolejne numery. W calcu nie wiem, jak to jest.

[Rafkus]

tabela w górnej części formularza pokazuje wszystkie rekordy,(...)coś w rodzaju pliku tymczasowego .tmp.

Dobrze zrozumiałeś.

(...) jako pierwszej, czynności logowania?(...)

Nie ma problemu, Z menu narzędzia wybierz Dostosuj, na karcie Zdarzenia przypisz makro Dialog do wydarzenia Otwórz dokument i zapisz. Od tej chwili, w trakcie otwierania formularza zostanie wywołane okno logowania.
Co do komunikatu „Plik z danymi użytkowników nie jest dostępny”.
Otóż w obecnej wersji jest zastosowana wersja hybrydowa z przechowywaniem danych użytkowników tzn. dane czterech z nich są przechowywane w makrze, a reszta w zewnętrznym pliku tekstowym. Na karcie Właściwości użytkownika (menu Plik--->Właściwości) jest podana ścieżka do pliku z loginami i hasłami użytkownika na MOIM komputerze (właściwość Loginy), u Ciebie tego pliku pewnie jeszcze nie ma więc albo podaj tam poprawną ścieżkę, albo wyczyść tam wpisaną wartość. To jest wada trzymania danych użytkowników w pliku zewnętrznym, podczas awarii sieci - nikt z pliku się nie zaloguje.

Zastanawiam się tylko nad kwestią zabezpieczenia tych plików

może @Jermor coś doradzi, ewentualnie wpisać ją na stałe do makra (ale to nie zabezpieczy go przed przypadkowym znalezieniem)...

Czy dopisywane rekordy mogą być numerowane automatycznie?

nie ma problemu, poniższe wyrażenie:

Kod: Zaznacz cały

i=getLastUsedRow(Ark)+1

podaje numer pierwszego wolnego wiersza w rejestrze, można ją bez problemu wpisać do jakieś komórki wraz z innymi danymi.

[Rafkus]

Zmieniłem położenie wątku i jego nazwę, myślę, że obecne jest bardziej odpowiednie do tego tematu.

Co do edycji, załóżmy sytuację:
Użytkownik A dokonał zapisu do rejestru. Po chwili chce dokonać pewnych zmian, nikt nie nadpisał żadnych danych więc to jest możliwe, rozpoczyna edycję.
W tym czasie użytkownik B dokonał zapisu.
Użytkownik A skończył edycję i... jak powinien zachować się formularz pozwolić na zmiany, czy też nie? A może powinien na czas edycji zablokować możliwość dodawania danych (otworzyć dokument Rejestru), tylko w tym przypadku
to już nieważne: =obawiam że się, że plik może potem "wisieć" u danego użytkownika przez czas nieokreślony...=poniżej właściwe pytanie
ile czasu dać mu na poprawę dokumentu??

[Jermor]

Ochrona pliku haseł.
Plik jest obsługiwany z wnętrza makra. Jeśli makro będzie zapisane w chronionej bibliotece, to nikt kto nie złamie hasła dostępu do biblioteki nie dowie się skąd plik jest pobierany.
Niezależnie od tego pamiętajmy, że każdemu plikowi możemy nadać dowolną nazwę. Ja w przykładzie wspomniałem o hsl.txt ale równie dobrze można nadać plikowi nazwę r12.png, czyli nazwę, która nie będzie potencjalnemu intruzowi nic sugerować, a raczej sugerować, że jest to jakaś grafika. Ponadto plik umieścic w jakiś folderze nie wzbudzającym podejrzeń, choćby w "Program Files\LibreOffice\program".
Nawet jeśli ktoś ostatecznie otworzy taki plik, to zobaczy nazwy użytkowników i pewne liczby. Te liczby nie są hasłami, więc ich znajomość niczym nie grozi. To przecież nie te liczby należy podać jako hasła. Groźnym jest poznanie algorytmu obliczającego te liczby. Algorytm jest jednak chroniony w makrze. W tym wypadku należałoby go zmodyfikować po swojemu. Ten zastosowany podałem jawnie w poście, pokazując jak można zaszyfrować hasło, więc każdy kto czytał posty go zna.
Wspomniałem także, że opisana przeze mnie procedura ma za zadanie utrudnić dostanie się do pliku. Nie zakładałem, że chodzi o procedurę TOP SECRET. Na takie proste szyfrowanie zawsze znajdzie się metoda, chociaż zwykły użytkownik zapewne nie wpadnie łatwo na sposób rozszyfrowania.

[andro]

W kwestii zabezpieczenia plików, czy wrzucenie haseł i loginów obok całego makra, do biblioteki opatrzonej hasłem, nie załatwia sprawy?
Być może @Jermor wymyśli jakiś sposób. Na marginesie, mam nadzieję, że nas tu znajdzie
Teraz hipotetyczna, chociaż bardzo realna do zaistnienia sytuacja, o której piszesz. Użytkownik pomimo, że zapisze swój rekord, ale nie opuści Rejestru, cały czas czas go blokuje. Tak więc następny użytkownik, wchodząc do Rejestru, dostaje komunikat o jego zajętości. Wprowadza dane, zapisuje swój rekord, który się pojawia w tabeli tymczasowej. Gdy pierwszy użytkownik stwierdzi, że zapisany rekord jest poprawny i dokonane zmiany (jeśli tego dokonał) są ostatecznymi, wychodzi z Rejestru. W tym momencie użytkownik, którego rekord "wisi" otrzymuje komunikat o zwolnieniu Rejestru i dodaniu jego rekordu do Rejestru. Nie wiem, czy tak to miało wyglądać?
Przy tej okazji trzeba byłoby się zastanowić (i o to pytasz) ile dać danemu użytkownikowi czasu na wprowadzenie rekordu, ew. poprawki, zapisanie i wyjście z Rejestru.
Wyżej pisałem, że będzie to Rejestr składający się z ok. 20 pól do wypełnienia, więc biorąc pod uwagę różne sytuacje, można spróbować ustawić na 10 min. Nie, czy nie za dużo?
Zastanawiam się właśnie nad sytuacją, co by się stało, gdyby ów drugi użytkownik, który czeka w kolejce z zapisanym w tymczasowym pliku rekordzie na zwolnienie Rejestru, zamknie w końcu Formularz twierdząc, że nie ma czasu czekać. Czy wówczas wiszący rekord nie powinien się automatycznie dopisać do Rejestru, zaraz po tym, jak go opuści blokujący go użytkownik? Nie wiem, czy coś takiego może istnieć?
Co prawda zamykając w ten sposób formularz użytkownik ten nie będzie wiedział pod jaką pozycją zapisany jest jego rekord. No ale wejście i podejrzenie Rejestru mu to pokaże.
Skoro jestem przy podglądaniu. Czy z tej funkcjonalności można korzystać, w chwili, gdy Rejestr jest zajęty? Dobrze byłoby w ten sposób mieć możliwość sprawdzić, jakie rekordy są już "na sztywno" dodane do Rejestru.

[Rafkus]

@Jermor nas znalazł, odpowiedział na posta tuż przed tobą.
Co do podglądania to od tego masz przycisk podejrzyj rejestr - uruchamia go w wersji tylko do odczytu więc nie blokuje.
Czyli dokument ma "wisieć" 10 min... fakt, troszkę długo.

użytkownik, którego rekord "wisi" otrzymuje komunikat o zwolnieniu Rejestru i

NIE otrzymuje żadnego komunikatu, musi sam co jakiś czas próbować zapisać.

zapisanym w tymczasowym pliku rekordzie na zwolnienie Rejestru, zamknie w końcu Formularz twierdząc, że nie ma czasu czekać. Czy wówczas wiszący rekord nie powinien się automatycznie dopisać do Rejestru, zaraz po tym, jak go opuści blokujący go użytkownik?

Uffffffffffffffffff, ten temat sobie odpuszczę.

[Rafkus]

Przedstawiam nową wersję formularza
Nowe zmiany to:
- Dopóki się nie zalogujesz praktycznie wszystkie przyciski i pola danych są zablokowane,
- Dodany przycisk Prześlij, pozwala na bezpośrednie przesłanie danych z tabeli tymczasowej do rejestru
- Działa usunięcie ostatnich danych
- Działa Edycja ostatnich danych, z tym że:

• - tak jak chciałeś po włączeniu edycji zaczyna odliczać się czas 10 min do autozapisu i zamknięcia rejestru
  - na czas edycji zablokowane zostają niektóre przyciski (zapisz, usuń, edycja, prześlij)
  - jeśli ktoś wyłączy rejestr wcześniej, nastąpi błąd podczas zapisu, zalecam później ponowne zalogowanie
  - Czas edycji wydawał mi się troszkę długi, dodałem więc kolejne pole wyboru i teraz makro sprawdza co 10 sek jaka jest w nim wartość. Jeżeli zostanie ono wybrane to w przeciągu krótkiej chwili nastąpi zapis i zamknięcie rejestru
  - gdyby podczas edycji jakieś pole-a zostało wyczyszczone to podczas zapisu, wartość w tym polu nie zostanie zmieniona (zostanie stara wartość)

. Pozostawiam go do testów.

[andro]

Jestem pod wrażeniem, dziękuję. Biorę się za testy