IFAR
Internetowe Forum Archiwalne => System informacji o zasobie archiwów państwowych => Wątek zaczęty przez: Anna Laszuk w Grudzień 20, 2006,
-
Rozmawiamy o EAD, rozmawiać też możemy o aktualnie przygotowanym narzędziu do opracowywania inwentarzy w wersji elektronicznej. Nowa wersja IZA 6.0 ma poszerzony moduł opisu dokumentacji kartograficznej oraz dodany moduł opisu materiałów ulotnych dostosowywany do przygotowywanych wskazówek metodycznych do opracowywania tych materiałów. Omawiana była wczoraj na posiedzeniu zespołu Informatyka i Archiwa i ustalono, że będzie testowana jeszcze w styczniu. Osoby zainteresowane tą wersją i jej testowaniem proszę o zgłaszanie się do mnie lub do Marka Kuczyńskiego.
Na uwagi czekamy po Świętach i po Nowym Roku, a na najbliższy okres życzę radosnych chwil wytchnienia przy kolędach i blasku choinkowych świateł.
-
Witam
Taki tu spokój... :P
Na początek sugestia: może warto skorzystać z okazji wprowadzenia nowej wersji i pokusic się o wprowadzenie jej do obligatoryjnego stosowania...?
To co cieszy:
- przycisk odysłający do raportu wydruku w formularzu edytor dokumentacji
- oznaczenie bieżącej sygnatury w nagłówku tegoż formularza
- wydruk serii z liczbą j.a. i datami (nie trzeba będzie montować samodzielnie :P )
To co nie działa:
- Wyświetlanie podserii w formularzu edytor dokumentacji. Problem polega na tym, że w polu z nazwą podserii wyświetlają się tylko nazwy podserii pierwszej serii w zespole, mimo, że identyfikatory są wlaściwe. Jeśli dany identyfikator nie wystepuje jako identyfikator podserii w serii pierwszej wówczas nie wyświetla się w polu nazy nic, jęsli zaś jest to taki sam identyfikator jak wystepujący w pierwszej serii wówczas wyświeętla się nazwa odpowiadającej mu podserii, ale z serii pierwszej.
- Import. Błąd przy przenoszeniu danych z wcześniejszej IZY
W kwerendzie dołączającej IZA06 w kolumnie PISMO jest w polu dołącz do: RODZAJPISMA i analogicznie w kolumnie RODZAJPISMA jest PISMO w efekcie dane trafiają do niewłaściwych kolumn
- Wyszukiwanie. Wyszukiwarka nie przeszukuje indeksów.
To co budzi wątpliwości
- Długość pola identyfikatora podserii. W tabeli podseria - podid powinno mieć ograniczoną długość do 8 znaków, bo w tabeli inwentarz jest takie ograniczenie.
Ale na marginesie trzeba zauważyć, że identyfikator serii ma długość 10 znaków, a podserii tylko 8 znaków – tak było i w poprzedniej IZIE. W sumie nie bardzo wiem skąd to ograniczenie?
- Czy na pewno rezygnacja z granic chronologicznych przy wyszukwianiu jest dobrym pomysłem?
- W edytorze dla dokumentacji... brak możliwości przechodzenia pomiędzy polami nazwa serii, podserii i wpisywania początku nazwy serii/podserii (a taką możliwość sugerują strzałki pół rozwijanych) – nie jest to opcja niezbędna, ale ułatwiała dotychczas życie.
To co budzi największą wątpliwość:
- Dlaczego pojawił się moduł opisu materialów ulotnych (sam w sobie oczywiście potrzebny) ale oparty na projekcie wskazówek, podczas gdy nie ma modułu do opisu fotografii a wskazówki już obowiązują?
-
Witam
To co zastanawia
Wprowadzenie dodatkowego pola zawierającego nazwę obcojęzyczną. Nie bardzo rozumiem sens tego posunięcia. IZA ma być bazą dla opisu na poziomie jednostki (i niżej) a nazwa zespołu funkcjonowaą powinna na poziomie opisu zespołu (Sezam). Wydawało mi się, że istniejąca dotychczas nazwa zespołu jest tylko swoistym pomostem pomiędzy obiema bazami i w przypadku ich połączenia w oczywisty sposób stanie się zbędna (wraz z całą tabelą ZESPOŁY). Skąd więc teraz idea nazwy obcojęzycznej?
PS. Piszcie ludzie - będziecie tej bazy używać i narzekać!
-
Witam
PS. Piszcie ludzie - będziecie tej bazy używać i narzekać!
W sensie - że jeśli nie zgłosicie uwag, nie będziecie mieć prawa narzkać, że to czy tamto Wam nie odpowiada, a nie w sensie że baza kiepska :P
-
Dzięki za uwagi! Poza Panem nikt nie zgłosił (do mnie) chęci obejrzenia tej wersji bazy danych, więc może dlatego nie ma uwag.
-
Uwagi do bazy IZA 6.0 z AP Poznań przedstawiliśmy na posiedzeniu zespołu "Informatyka i Archiwa", które odbyło się w naszym archiwum w grudniu 2006 r. Wtedy też trochę ponarzekaliśmy :D .
Ale jeśli jeszcze coś nam się nasunie, na pewno to zgłosimy.
Jeśli chodzi o nazwę obcojęzyczną twórcy zespołu: skoro IZA 6.0 generuje stronę tytułową inwentarza, powinna być ona zgodna z obowiązującymi przepisami, a przewidują one zamieszczenie obcojęzycznej nazwy.
-
Witam
Co do strony tytułowej - fakt: IZA 6,0 generuje stronę i fakt, że tej opcji niektórym użytkownikom brakowało w IZIE 5,0. Ale czy gra jest warta świeczki? To znaczy czy warto do bazy wprowadzać dodatkowe dane tylko po to, by je otrzymać na wydruku? Strona tytułowa dostępna z IZY 6,0 będzie i tak musiała być edytowana w Wordzie zawsze gdy w zespole wystąpią priora i posteriora, a taka sytuacja nie jest przecież rzadkością.
-
- Czy na pewno rezygnacja z granic chronologicznych przy wyszukwianiu jest dobrym pomysłem?
Z tego co wiem było to podyktowane tym, że strasznie przedłużało to wyszukiwanie. Osobiście robiłem testy na kilku komputerach w naszym archiwum (na IZIE 5.0) i średni czas wyszukiwania z uwzględnieniem granic chronologicznych (po przeniesieniu wszystkich danych) to, o ile pamiętam, 8-9 minut, na niezłej klasy komputerze :shock: . To samo wyszukiwanie bez kryterium chronologicznego - ok. 40-45 sekund. Poza tym wynik wyszukiwania można samemu ułożyć narastająco i na jedno wyjdzie. Nie wspominając o tym, że jednostki bez dat i tak nie były przecież ujęte w takim wyszukiwaniu. To chyba gra niewarta świeczki...
Niestety, masz Wojtku rację, że indeksy nie są przeszukiwane przy wyszukiwaniu pełnotekstowym, co rzeczywiście koniecznie trzeba poprawić :(
-
Jeśli chodzi o nazwę obcojęzyczną twórcy zespołu: skoro IZA 6.0 generuje stronę tytułową inwentarza, powinna być ona zgodna z obowiązującymi przepisami, a przewidują one zamieszczenie obcojęzycznej nazwy.
Zasadniczo zgoda, ale - jak doskonale wiesz Hanno - ten sam przepis wskazuje, że na stronie tytułowej ma być umieszczone również nazwisko wykonawcy inwnetarza... Na razie IZA takiej formy strony tytułowej nie generuje.
Dzięki Macieju, teraz znam powody zmiany wyszukiwarki. U nas były podobne problemy. Ale z drugiej strony może nie trzeba wylewać mydła z kąpielą. Może wyszukiwarka powinna uwzględniać opcję przeszukiwania z uwzględnieniem dat? To znaczy jeśli ktoś sobie życzy zaznacza pole wyboru i dopiero wówczas uruchamia się kwerenda przeszukująca również daty? Wówczas ci, którym zależy na czasie rezygnowaliby z przeszukiwania dat, a ci, którym zależy bardzo na datach wychodziliby na kawę :P .
-
To co zapewne by ucieszyło:
Przy podglądzie pełnych danych na temat danej jednostki w wynikach wyszukiwania nie można oglądnąć zawartości pól: "tytuł tłumaczony" i "treść/zawartość". (Podobnie było w IZIE 5,0) Sądze, że taki podgląd byłby opcją przydatną, zwłaszcza w sytuacji gdy wysukiwane słowo znajduje się właśnie tam.
-
Witam
Tak, wiem, powtarzam się... Ale może warto rozważyć wprowadzenie bazy danych IZA jako obowiązkowej? Jest okazja, bo najnowsza wersja już u bram, więc może przy okazji...? Wydaje mi się to tym istotniejsze, że - jeśli wszystko pójdzie dobrze - wkrótce otrzymamy do rąk kompleksowe narzędzie w postaci Zintegrowanego Systemu. Nie wyobrażam sobie żeby również on był narzędziem fakultatywnym. A skoro się już pojawi nie powinniśmy ryzykować zaskoczenia archiwistów, którzy dotychczas nie pracowali z bazą IZA, że nagle muszą przesiąść się przed komputery. Może warto wprowadzając IZĘ jako obowiązkową kierować się nadzieją, że będzie ona służyć archiwistom w oswajaniu się z nowym stylem pracy?
-
Pewnie, że pomysł jest dobry. Sam wielokrotnie zastanawiałem sie dlaczego IZA nie jest obowiązkowa, także na tym forum. (m.in. http://www.ifar.lublin.ap.gov.pl/ifarforum/viewtopic.php?t=548&start=0). To rzeczywiście jest dobry moment, ale obawiam się że nic z tego. Pozostaje mieć nadzieję że Zintegrowany System będzie obowiązkowy. Bo skoro SEZAM jest obowiązkowy, a też bedzie częścią tego systemu, to może jest jakaś nadzieja... :?:
-
Oczywiście, zgadzam się całkowicie.
Ale częścią tego systemu mają być też inne bazy, które też nie są obowiązkowe, a w tym kontekście powinny być. No bo co to za Zintegrowanany System, w którym np. baza SCRINIUM będzie wypełniana tylko w kilku archiwach...
-
Witam
Się doczekaliśmy ;)
Baza IZA 6,0 właśnie dotarła do archiwów. Myślę, że powymieniamy się uwagami na jej temat w tym wątku.
-
I podobno ma być obowiązkowa...
-
???
A o tym nic nie wiem: oprócz bazy i instrukcji nie dostaliśmy żadnego zarządzenia.
-
Napisałam: "podobno" :)
-
Zapewne wkrótce sie dowiemy ;)
A co do bazy:
Pole PODID w tabeli Podseria pozwala na wprowadzenie identyfikatora do 50 znaków - i bardzo dobrze, bo bywają zespoły o złożonej strukturze, w których trzeba wprowadzić dużo podserii, a jeśli robi się to w trakcie inwentaryzacji swoboda tych 50 znaków jest znakomitym ułatwieniem. Tyle, ze w tabeli Inwentarz pole Podseria ma już tylko 8 znaków, co uniemożliwia wykorzystanie podserii o dłuższych identyfikatorach.
-
I jest nowy "Podręcznik użytkownika"...
Całkiem nowy :)
-
Coś z wyświetlaniem podserii w formularzu jest nie tak... Jednostki można dopasować i na wydruku są we właściwych seriach, ale w formularzu dzieje się to co już opisywałem:
- Wyświetlanie podserii w formularzu edytor dokumentacji. Problem polega na tym, że w polu z nazwą podserii wyświetlają się tylko nazwy podserii serii dopasowanej do pierwszego rekordu(?) w zespole, mimo, że identyfikatory są właściwe. Jeśli dany identyfikator nie występuje jako identyfikator podserii w serii pierwszej wówczas nie wyświetla się w polu nazwy nic, jeśli zaś jest to taki sam identyfikator jak występujący w pierwszej serii wówczas wyświetla się nazwa odpowiadającej mu podserii, ale z serii pierwszej.
-
Witam
Trochę sie powtórze, ale cóż...
- Import. Błąd przy przenoszeniu danych z wcześniejszej IZY
W kwerendzie dołączającej IZA06 w kolumnie PISMO jest w polu dołącz do: RODZAJPISMA i analogicznie w kolumnie RODZAJPISMA jest PISMO w efekcie dane trafiają do niewłaściwych kolumn
- Wyszukiwanie. Wyszukiwarka nie przeszukuje indeksów.
To co zapewne by ucieszyło:
Przy podglądzie pełnych danych na temat danej jednostki w wynikach wyszukiwania nie można oglądnąć zawartości pól: "tytuł tłumaczony" i "treść/zawartość". (Podobnie było w IZIE 5,0) Sądze, że taki podgląd byłby opcją przydatną, zwłaszcza w sytuacji gdy wysukiwane słowo znajduje się właśnie tam.
-
Witam,
To chyba dobry pomysł?
Pozdrawiam,
-
Witam
W nawiązaniu do:
Pole PODID w tabeli Podseria pozwala na wprowadzenie identyfikatora do 50 znaków - i bardzo dobrze, bo bywają zespoły o złożonej strukturze, w których trzeba wprowadzić dużo podserii, a jeśli robi się to w trakcie inwentaryzacji swoboda tych 50 znaków jest znakomitym ułatwieniem. Tyle, ze w tabeli Inwentarz pole Podseria ma już tylko 8 znaków, co uniemożliwia wykorzystanie podserii o dłuższych identyfikatorach.
Właśnie mam nieodpartą ochotę użyć podserii z identyfikatorem dłuższym niż 8 znaków... Ale póki co będę musiał pozmieniać kilka sąsiednich identyfikatorów żeby kolejną podserię umieścić tam, gdzie mi się zamarzyło. :(
Bardzo nalegam na zwiększenie pola z identyfikatorem podserii.
-
Właśnie mam nieodpartą ochotę użyć podserii z identyfikatorem dłuższym niż 8 znaków...
Zdradź nam Wojtku, co to za identyfikator, że ma aż 8 znaków???
-
Widzę, że Kolega nie dowierza ;)
07965277
Paskudny, prawda? Ale cóż robić zespół też nie daje się łatwo systematyzować.
-
Nie będę owijał w bawełnę - sam sobie tak systematyzację umyśliłem i muszę sobie z tym radzić. Ale wydaje mi się, że ograniczenie fantazji archiwsty w tym względzie do 8 (a dlaczego nie 7 albo 9?) znaków nie znajduje uzasadnienia.
-
Jesteśmy we właściwym wątku, więc się powtórzę:
koleżanka też nie dowierza :o
Po twoim nowym poście, Wojtku, nie dowierzam podwójnie :o :o
-
No cóż... To ci dopiero identyfikatorzysko ;)
Ale skoro jest problem. Jeśli moge coś doradzić - to jak najszybsze wycofanie się z tego sposobu. A jeśli nie - skontaktowanie się z COIA z zapytaniem, czy są przeciwwskazania do tego, żebyście indywidualnie zwiększyli pole ID i PODID na tyle ile chcecie. Tabele powinny być zestandaryzowane, ale skoro istnieje potrzeba... IZA 6.0 poszła już "do ludzi", a więc poprawianie jej teraz raczej pewnie nie wchodzi w grę...
A tak z ciekawości - czy na etapie zgłaszania poprawek sygnalizowałeś taką potrzebę? I jak radziłes sobie z poprzednia IZĄ (5.0)? Czy tam pole na ID było większe (nie wiem bo nie używałem IZY 5.0)?
-
Koledzy, uspokójcie się :)
Nie wiem, może to upał tak działa ;D
Za chwilę w ogóle stracę wiarę w rozsądek archiwistów :(
-
Ale skoro jest problem. Jeśli moge coś doradzić - to jak najszybsze wycofanie się z tego sposobu. A jeśli nie - skontaktowanie się z COIA z zapytaniem, czy są przeciwwskazania do tego, żebyście indywidualnie zwiększyli pole ID i PODID na tyle ile chcecie. Tabele powinny być zestandaryzowane, ale skoro istnieje potrzeba... IZA 6.0 poszła już "do ludzi", a więc poprawianie jej teraz raczej pewnie nie wchodzi w grę...
Jeśli zmienimy tabele to pewnie nie da sie ich scalić w COIA przed prezentację w necie więc ta droga odpada.
A tak z ciekawości - czy na etapie zgłaszania poprawek sygnalizowałeś taką potrzebę?
Pisałem o tym w styczniu w tym wątku - wtedy zwracałem uwagę tylko na różne długości pól seria (10 znaków) i podseria (8 znaków).
I jeszcze tu: http://www.lublin.ap.gov.pl/ifar/ifarforum2/index.php?topic=491.0
I jak radziłes sobie z poprzednia IZĄ (5.0)? Czy tam pole na ID było większe (nie wiem bo nie używałem IZY 5.0)?
Mówię cały czas o IZA 5,0. A zależeć na dłuższych identyfikatorach zaczęło mi mocno dziś ;)
Oczywiście sporo racji ma też Hania - nie ma sensu wywracać bazy do góry nogami z powodu fanaberii jednego archiwisty ;) Ale może warto zrobić w bazie porządek: jeśli seria ma długość 10 znaków to niech i podseria ma 10 (choć nadal nie wiem dlaczego). A może, skoro formularz już pozwala na wpisywanie 30 znaków, wydłużyć te pola w tabeli INWENTARZ do 30 znaków?
-
witam
mała praktyczna uwaga dla konwertujących izę 6.0 z access2000 do access97
trzeba ręcznie dodać w module sortowanie definicję funkcji StrReverse przed jej użyciem
access2000 ma ją predefiniowaną, a access97 niestety nie - wystarczy wkleić:
Function StrReverse(Expression As String) As String
Dim i As Long
Dim strTmp As String
For i = Len(Expression) To 1 Step -1
strTmp = strTmp & Mid$(Expression, i, 1)
Next
StrReverse = strTmp
End Function
dokładniejsze info po hiszpańsku ;D
http://accessvbafaq.mvps.org/item.asp?pagina=8
pamiętajcie w COIA o archiwach, które mają starsze komputery !!!
pozdrowienia
-
Witam
I podziwiam... Też zdarzyło mi się konwertować IZĘ do wersji 97 Accessa i nie wspominam tego dobrze: powstała trochę kulawa baza, która tylko z konieczności jest wykorzystywana, acz i tak marginalnie. Na szczęście nie było problemów z uzyskaniem licencji na Accessa 2000 z NDAP. Właściwie więc sprawa rozbija się nie o jakość sprzętu a o licencje - jeśli na komputerze "chodzi" Access 97 to i Access 2000 nie powinien mieć problemów (Co oczywiście nie oznacza, że komfort pracy z bazą danych zapewni procesor 300 MHz i 64 MB RAM ;)).
-
Obiecałam sobie solennie, że nie wypowiem się w tym wątku, bo kilkuletnie już dyskusje nad kolejnymi wersjami bazy IZA są po prostu nudne, bo w rezultacie i tak dostajemy do pracy produkt ułomny >:(
Ale po dzisiejszych doświadczeniach z IZĄ postanowiłam jednak zabrać głos. Skończyłam inwentaryzować zespół w nowej bazie: kosztowało mnie to sporo nerwów, bo co chwilę wychodziły jakieś uciążliwe niedoróbki i usterki, ale cóż, można się przyzwyczaić albo coś tam poprawić >:(
Ale dzisiejsze "wyczyny" IZY przeszły wszelkie moje oczekiwania. Otóż okazało się, że w wydruku serii podawana jest błędna liczna jednostek archiwalnych wchodzących w skład danej serii, bo liczone są ciągi dat w j.a. Jeśli więc seria składa się z 1 j.a., a nie daj Boże wypiszę 3 ciągi dat, to w zestawieniu serii otrzymuję liczbę j.a.: 3.
:o :o :o
>:( >:( >:(
-
Tak to właśnie jest, oddaje się bazę danych do testowania, nikt większości tego nie robi tylko czeka na wersję finalną, a później lament znowu źle liczy, znowu zły wydruk itp. Błąd oczywiście zostanie wyeliminowany za co z góry przepraszam.
-
Ja pragnę zauwazyć, że autorzy nie wzięli pod uwagę nośników dźwiękowych w celu ich zewidecjonowania. Przecież nie wsadzę filmu do dokumentacji aktowej, opiszę w uwagach co to jest i jeszcze podpiszę taśmę magnetyczna jako nośnik elekroniczny ;D
-
Z przykrością muszę dodać, że w bazie IZA nie można inwentaryzować także fotografii, filmów, pieczęci, dokumentów staropolskich, dokumentów elektronicznych i pewnie paru jeszcze innych rodzajów dokumentacji. Bazę jednak rozwijamy stopniowo, więc i na to przyjdzie czas. Chyba że wcześniej opracowany zostanie system zintegrowany – bardziej wszechstronny niż pojedyncze bazy.
-
Chyba że wcześniej opracowany zostanie system zintegrowany – bardziej wszechstronny niż pojedyncze bazy.
Błagam nie róbmy kolejnych małych baz tylko rozpiszmy przetarg na budowę jednej doskonałej wersji, która przez rok testować będą archiwa o największym zasobie. Po okresie próbnym reszta archiwów.
-
Witam
Błagam nie róbmy kolejnych małych baz tylko rozpiszmy przetarg na budowę jednej doskonałej wersji, która przez rok testować będą archiwa o największym zasobie. Po okresie próbnym reszta archiwów.
A więc nie jeden przetarg, ale dwa: pierwszy na wersję do testowania, drugi na wersje ostateczną... doskonałą? To może potem trzeba będzie rozpisać trzeci na poprawki? Pani Evo zauważyła Pani na pewno w dziale NAC forum zapowiedzi budowy systemu zintegrowanego pozwalającego opisywać w jednym "miejscu" różne rodzaje dokumentacji i łączyć te opisy z kopiami (później oryginałami) cyfrowymi. Czy uda się stworzyć system doskonały? Pewnie nie, ale na pewno będzie to najlepszy system, jaki mogą zbudować archiwa. Kiedy? Terminy podane są tutaj (http://archiwa.gov.pl/repository/decyzje/zarz_7_2007.pdf).
-
Po miesiącu korzystania z bazy IZA 6 i w związku z tym, że niewiele osób nt. tej wersji bazy się wypowiada (no... chyba, że nie jest stosowana w archiwach ???) chciałbym zwrócić uwagę na kilka niedogodności występujących podczas pracy:
1. Błąd: Aparat bazy danych Microsoft Jet zatrzymał proces, nieważ inny użytkownik próbuje jednocześnie zmienić te same dane (nawet jeśli pracuje się samemu) pojawiający się przy wersji 5 średnio co 10-ty rekord teraz pojawia się zwykle tylko przy początkowych rekordach, za to regularnie i komunikat ten jest czasem niemożliwy do likwidacji (nie można przejść do jakiegokolwiek pola). Możliwe, że ilość danych w tabeli jest nie do „przerobienia” przez Acccessa.
2. Układ formularza jest bardzo niewygodny: przy zmieniających się seriach/podseriach trzeba najpierw wpisać kolejną sygnaturę, a potem wrócić w górę i zmienić serie. Ponadto przy zmianie serii i podserii w poprzedniej wersji wystarczyło wpisać początkowe litery nazwy, a teraz trzeba rozwijać jedno i drugie (osobiście jest mi łatwiej zapamiętać nazwę, niż identyfikator cyfrowy).
3. Przy kopiowaniu rekordu, w opisie nie kopiują się okna daty i osoby opisującej – wpisywanie ich przy każdym nowym rekordzie, kilkadziesiąt razy dziennie jest kłopotliwe.
4. Przejrzenie wydruku z bazy trwa nieporównywalnie długo w stosunku do poprzedniej wersji. Ogólnie baza działa zauważalnie wolniej od poprzedniej wersji.
5. Nadal brak pola do sortowania jednostek w ramach serii/podserii w przypadku, gdy konieczne jest zastosowanie innego układu niż np. chronologiczny. Sytuacja ma miejsce np. przy aktach gruntowych w sądach obwodowych, które układa się wg numeru nieruchomości w ramach poszczególnych miejscowości (podseria) i grupie akt gruntowych (seria), albo przy testamentach, które układamy alfabetycznie. Wykorzystujemy tu pole „sygnatura dawna”, ale czasem chciałoby się tam rzeczywiście wpisać dawną sygnaturę...
6. Nadal nie rozumiem czemu służą przyciski indeksów w formularzu wyszukiwarki. Sama wiedza, że w indeksie występuje dana nazwa, niczego nie daje, jeśli nadal nie wiadomo, w której jednostce ona występuje. Nie rozumiem również, dlaczego wyszukiwarka w trybie pełnotekstowym nie przeszukuje indeksów. W zamian za to wydaje się, że wyszukiwarka działa nieco szybciej od wersji 5.
-
witam
5. Nadal brak pola do sortowania jednostek w ramach serii/podserii w przypadku, gdy konieczne jest zastosowanie innego układu niż np. chronologiczny. Sytuacja ma miejsce np. przy aktach gruntowych w sądach obwodowych, które układa się wg numeru nieruchomości w ramach poszczególnych miejscowości (podseria) i grupie akt gruntowych (seria), albo przy testamentach, które układamy alfabetycznie. Wykorzystujemy tu pole „sygnatura dawna”, ale czasem chciałoby się tam rzeczywiście wpisać dawną sygnaturę...
Znowu wypływa sprawa dodatkowych pól przeznaczonych dla sortowania. Jedni chcą więcej poziomów (podpodserie) a inni - jak Henryk - dodatkowych pól w ramach podserii. Trzeba chyba temu stawić czoło, żeby archiwiści nie uciekali sie do tak karkołomnych praktyk o jakich wspomina Henryk. Pewien pomysł zarysowałem tu (http://www.lublin.ap.gov.pl/ifar/ifarforum2/index.php?topic=884.15).
-
#1 zauważyłam w: materiałach ulotnych, że w opisie jednostki jak się zapomni wpisać z czym mamy do czynienia (np. ulotka) IZA przy wydruku pominie tą jednostkę. Natomiast inwentarz skarbowy wykaże, że dana jednostka jest...ciekawe nie?
#2 i jeszcze jeden smaczek, Iza jest tak ustawiona, że przy wydruku przy dokumentacji technicznej pomija autora.
-
1) Szkoda, że spod edytora nie widać od razu, czy jednostka ma jakiś opis w polu treść. Rozumiem, że przy Accesie nie da się tak zrobić (jakimś widocznym znaczkiem choćby), a jedynie przez zwiększenie głównego formularza o to właśnie pole (zamiast osobnego "podokienka").
2) Niezbyt wygodna jest teraz konieczność dodawania języków przez wchodzenie do parametrów bazy, podwójne kliknięcie w polu język było lepszą opcją.
-
Witam,
1) Szkoda, że spod edytora nie widać od razu, czy jednostka ma jakiś opis w polu treść. Rozumiem, że przy Accesie nie da się tak zrobić (jakimś widocznym znaczkiem choćby), a jedynie przez zwiększenie głównego formularza o to właśnie pole (zamiast osobnego "podokienka").
Zgadza się - można w prosty sposób mieć podgląd pola treść już w formularzu inwentarza dokumentacji aktowej. Pole "treść" jest w osobnym formularzu zapewne po to, by nie powiększać - już rozbudowanego - formularza. Ale to prosta modyfikacja i dla celów, o których pisze Kocibrzuch wystarczy niewielkie pole, w którym widać będzie tylko początek pola "treść".
-
Jeszcze jedna odnośnie tego uwaga. Choć wyszukiwarka przeszukuje pole treść (na szczęście), to jednak w wynikach wyszukiwania go nie pokazuje, nawet na widoku pojedynczej tak odnalezionej jednostki.
-
Apropos bazy. Szczerze mówiąc nie ma się czym podniecać. Osobiście wolałem 4 - była prostsza, a tutaj tyle pól.
-
Nie tylko Pan ją wolał. Niektórzy chyba nadal ją wolą i stosują.
A odpowiadając na uwagi dotyczące rozmieszczenia informacji w różnych formularzach - przypominam, że bazy zrobione w programie Access i przesyłane do archiwów nie mają postaci skompilowanej. Można w nich dokonywać potrzebnych zmian - modyfikować formularze, kwerendy, raporty. Nie można jedynie zmieniać struktury tabel, bo to utrudnia lub uniemożliwia w konsekwencji scalanie danych przed ich wspólnym udostępnieniem.
-
W formularzu wyników wyszukiwania pole uwagi ma ograniczenie wyświetlania do 256 znaków. Jak to zmienić?
-
W formularzu wyników wyszukiwania pole uwagi ma ograniczenie wyświetlania do 256 znaków. Jak to zmienić?
Rzuciłem okiem na tę kwestię i chyba nic z tego. Standardowe połączenia tabel w kwerendzie, bez konstrukcji wyrażeń. Wygląda na to, że Access przy indeksowaniu może utworzyć łącze jedynie do pierwszych 255 znaków i w kwerendzie nie ma znaczenia
czy odnosi się do pola Tekst czy pola Nota/memo w tabeli. W widoku projekt nie widzę niczego, co możnaby zmienić w tej materii, a pole Uwagi w tabeli głównej jest ustawione jako "Nota". W wolnej chwili jeszcze sprawdzę.
-
Bardzo dziękuję.
Rozumiem, że ZOSiA takiego numeru mi nie wytnie.
-
Nie wytnie 8)
-
oj nie :)... ręczę za to :)
-
Szczerze mówiąc mam nieodparte wrażenie, że niektóre z tych baz robili czyści teoretycy którzy nie skalali swoja ręką porządkowania żadnej jednostki. Może to mocno brzmi ale tak wg mnie jest. Takie rozbudowywanie baz niczego dobrego nie wróży nadgonieniu porządkowania i inwentaryzacji. Nigdy nie wyjdziemy na prostą.
-
Na stronie archiwa.gov.pl ukazała sie informacja o planowanej w NDAP dyskusji wokół referatu p. H. Staszewskiej z AP Poznań pt. "Kierunki zmian w obowiązujących przepisach metodycznych w archiwach państwowych w kontekście wdrożenia zintegrowanego systemu informacji w archiwach państwowych - wybrane propozycje". Referat ten był przedmiotem zebrania naukowego w marcu 2008 r. w AP Poznań stąd też z oczywistych względów znam jego treść. Wykracza ona zdecydowanie poza wskazany w tytule kontekst. Znaczna część z postulowanych przez H. Staszewską zmian w przepisach metodycznych w archiwach państwowych powinna dokonać się nie dopiero przy okazji wdrażania Zosi, ile z racji przestrzegania narzuconych przez ogólną metodologię nauk najprostszych prawideł logiki. Autorzy różnego rodzaju przepisów składających się na instrumentarium metodyczne archiwistyki przez całe lata dość oszczędnie korzystali z owych prawideł. Można z dużą dozą prawdopodobieństwa przypuszczać, że wiecowo-referendalny sposób wypracowywania przepisów metodycznych w połączeniu z wyjątkową awersją do korzystania z zewnętrznych opinii eksperckich sprzyjał utrwalaniu się tego stanu rzeczy. Wydawać by się mogło, że nawet tak nieskomplikowana kwestia, jak opis fizyczny jednostek archiwalnych, nie powinna nastręczać większych problemów z przestrzeganiem elementarnych rygorów logiki .Tymczasem nawet na tym poziomie tak się niestety nie działo. Mam nadzieję, że postulowane przez H. Staszewską zmiany nie zostaną utopione w niekończących się dyskusjach w ramach komisji, podkomisji, zespołów, podzespołów itp. a archiwistyka polska wkroczy na ścieżkę pozwalającą jej opuscić pozycję jednego z głównych beneficjentów reguł logiki rozmytej wśród różnych dyscyplin wiedzy humanistycznej.
-
Szczerze mówiąc mam nieodparte wrażenie, że niektóre z tych baz robili czyści teoretycy którzy nie skalali swoja ręką porządkowania żadnej jednostki. Może to mocno brzmi ale tak wg mnie jest. Takie rozbudowywanie baz niczego dobrego nie wróży nadgonieniu porządkowania i inwentaryzacji. Nigdy nie wyjdziemy na prostą.
Faktycznie, mocno brzmi. I prawdziwe jest, zapewne, Pana odczucie, natomiast stan faktyczny jest inny. Większość autorów pracuje w archiwach i wszyscy, chyba poza informatykiem Markiem Kuczyńskim, porządkowali lub porządkują zespoły archiwalne.
Zwracam uwagę, że potrzeby i chęci opisywania archiwaliów bywają różne. Rozbudowane formularze w bazach inwentarzowych miały zaspokoić wiele zgłaszanych postulatów, co p. Choniawko nazwał "wiecowo-referendalnym sposobem wypracowywania przepisów metodycznych" przez zespoły naukowe, gdyż w dużej mierze bazy były dostosowywane do wskazówek metodycznych. Natomiast minimalny wykaz pól obowiązkowych miał umożliwić podstawową inwentaryzację.
O które bazy Panu chodzi? Może można będzie je poprawić, jeśli nie wchodzą do pierwszej wersji systemu ZoSIA.
-
W związku z tym, że swego czasu nie uzyskałem odpowiedzi, ponawiam swoje pytanie. Otóż mój problem przedstawia się następująco:
Podczas uzupełniania indeksów w bazie IZA, zawsze przy pierwszych rekordach, a czasem podczas dalszej pracy, pojawia się błąd z następującym komunikatem:
Aparat bazy danych Microsoft Jet zatrzymał proces, ponieważ inny użytkownik próbuje jednocześnie zmienić te same dane
Próba przejścia do jakiejkolwiek inne rubryki generuje kilkakrotne ponowienie tegoż komunikatu, po czym po kilkunastu lub kilkudziesięciu kliknięciach na OK, błąd ustępuje. Naturalnie nikt nie próbuje zmieniać tych danych. Zdarza się że nawet nikt inny nie uzupełnia w tym czasie bazy.
Przypuszczam, że problem może wynikać z tego, że jeden z komputerów w sieci, na którym się też normalnie pracuje, jest serwerem.
Zwracam się prośbą o pomoc, ponieważ nasz informatyk od 2 lat potrafi rozwiązać tego problemu. Możliwe, że w ogóle nierozwiązywalnego?
-
W związku z tym, że swego czasu nie uzyskałem odpowiedzi, ponawiam swoje pytanie. Otóż mój problem przedstawia się następująco:
Podczas uzupełniania indeksów w bazie IZA, zawsze przy pierwszych rekordach, a czasem podczas dalszej pracy, pojawia się błąd z następującym komunikatem:
Aparat bazy danych Microsoft Jet zatrzymał proces, ponieważ inny użytkownik próbuje jednocześnie zmienić te same dane
Próba przejścia do jakiejkolwiek inne rubryki generuje kilkakrotne ponowienie tegoż komunikatu, po czym po kilkunastu lub kilkudziesięciu kliknięciach na OK, błąd ustępuje. Naturalnie nikt nie próbuje zmieniać tych danych. Zdarza się że nawet nikt inny nie uzupełnia w tym czasie bazy.
Przypuszczam, że problem może wynikać z tego, że jeden z komputerów w sieci, na którym się też normalnie pracuje, jest serwerem.
Zwracam się prośbą o pomoc, ponieważ nasz informatyk od 2 lat potrafi rozwiązać tego problemu. Możliwe, że w ogóle nierozwiązywalnego?
Spróbujemy coś poradzić. Zakładam, ze problem istnieje na każdym komputerze, z którego wchodzi się do bazy.
Na początek (bazy zamknięte!) proponuję sprawdzić czy na serwerze w katalogu baz, w którym są pliki z danymi (np. izadane.mdb etc. w zależności jak macie system bazodanowy zorganizowany), czy nie ma przypadkiem pliku z rozszerzeniem *.ldb (izadane.ldb etc.). Jeśli jest - usunąć. Możliwe, że kiedyś wystąpił jakiś błąd i program nie zakończył poprawnie pracy. Przy próbie edycji może wyświetlać taki komentarz i niekoniecznie chodzi tu o drugiego użytkownika, tylko o równolegle działający gdzieś w tle proces edycji.
Jeśli z powyższym jest porzadek, spróbować można naprawić bazę. (Najpierw kopia zapasowa obowiązkowo!)
Wchodzimy do bazy. Z górnego Menu "Narzędzia" ---> "Narzędzia bazy danych" ---> Kompaktuj i napraw bazę danych. (Wg MS Office 2003; w wersji 2000 powinno być podobnie)
Parę słów na ten temat:
Narzędzie Kompaktuj i napraw
Narzędzie Kompaktuj eliminuje puste miejsce w istniejącej bazie danych, tworząc nową docelową bazę danych i kopiując każdy obiekt ze starej bazy danych do nowej. Jeśli zostanie wybrana opcja kompaktowania bazy danych do oryginalnej bazy danych o tej samej nazwie zamiast do nowej bazy danych, narzędzie Kompaktuj tworzy tymczasową bazę danych, eksportuje obiekty z oryginalnej bazy danych do tymczasowej bazy danych, usuwa oryginalną bazę danych i zmienia nazwę tymczasowej bazy danych na nazwę oryginalnej bazy danych.
Narzędzie Napraw próbuje naprawić w bazie danych tylko tabele, kwerendy i indeksy. Nie próbuje naprawić uszkodzonych formularzy, raportów, makr czy modułów. Poniżej podano listę akcji, które wykonuje narzędzie Napraw. ? Reorganizowanie stron tabeli, aby zostały umieszczone na sąsiednich stronach bazy danych. W wyniku tego zwiększa się wydajność, ponieważ tabele w bazie danych nie są już pofragmentowane.
? Zwolnienie nieużywanego miejsca na dysku, utworzonego po usunięciu obiektów i rekordów. Gdy obiekty lub rekordy są usuwane z bazy danych, miejsce przez nie zajmowane jest oznaczane jako dostępne dla nowych obiektów bazy danych. To oznacza, że jeśli baza danych nie zostanie skompaktowana, rozmiar bazy danych nigdy się nie zmniejszy. Zaleca się częste kompaktowanie baz danych zawierających często dodawane, usuwane i aktualizowane obiekty.
? Resetowanie zwiększającego się pola Autonumerowanie tak, że kolejna przydzielona wartość będzie o jeden większa od najwyższej wartości w pozostałych rekordach. Na przykład, jeśli wszystkie rekordy bazy danych zostały usunięte, po skompaktowaniu bazy danych wartość pola Autonumerowanie podczas dodawania nowego rekordu przyjmie wartość 1. Jeśli największą wartością pola Autonumerowanie będzie 50, po skompaktowaniu, podczas dodawania nowego rekordu pole przyjmie wartość 51. Należy zauważyć, że tak się stanie nawet wtedy, gdy rekordy zawierające wartości wyższe niż 50 zostały wcześniej dodane, ale przed kompaktowaniem usunięte.
? Ponowne generowanie statystyki tabel używanej z procesie optymalizacji kwerend. Te statystyki mogą po pewnym czasie stać się nieaktualne, zwykle wtedy, gdy została cofnięta transakcja lub jeśli baza danych nie była poprawnie zamknięta z powodu utraty zasilania lub awarii całkowitego zamknięcia programu korzystającego z aparatu Microsoft Jet przed wyłączeniem komputera.
? Flagowanie wszystkich kwerend, aby zostały ponownie skompilowane podczas następnego wykonania kwerendy. To jest ważne, ponieważ statystyka bazy danych może ulec zmianie i uprzednio skompilowane kwerendy mogą mieć nieprawidłowy plan kwerendy.
Baza danych nie może być otwarta przez innych użytkowników.
Odzyskiwanie uszkodzonej bazy danych
Następujące kroki przedstawiają ogólną metodę naprawiania uszkodzonej bazy danych: 1. Utwórz kopię uszkodzonego pliku bazy danych (mdb) w postaci kopii zapasowej.
2. Usuń plik ldb, jeśli jest obecny. Przed jego usunięciem należy zamknąć odpowiadający mu plik mdb.
Plik ldb jest używany do ustalania, które rekordy są zablokowane we współużytkowanej bazie danych i przez kogo. Jeśli baza danych jest otwarta dla współużytkowania, tworzony jest plik ldb o takiej samej nazwie, co odpowiadająca mu baza danych (mdb). Na przykład, jeśli zostanie otwarta (do współużytkowania) przykładowa baza danych Northwind.mdb w folderze c:\Msoffice\Access, w tym samym folderze zostanie automatycznie utworzony plik Northwind.ldb. Plik ldb jest automatycznie usuwany po zakończeniu pracy z bazą danych przez ostatniego użytkownika z wyjątkiem dwóch przypadków -- gdy ostatni użytkownik nie ma uprawnień do usuwania w folderze zawierającym plik mdb lub gdy baza danych jest uszkodzona. Plik ldb zawiera listę użytkowników, którzy mają otwartą bazę danych.
źródło (http://support.microsoft.com/default.aspx?scid=kb;pl;209137)
I na koniec - mało optymistyczne, ale miejmy nadzieję, że się nie potwierdzi:
Jeśli kompaktowanie i naprawa nie powiodą się, pojawi się odpowiedni komunikat. To będzie oznaczać, że uszkodzenia są poważne i nie mogą być usunięte.
Ewentualnie można jeszcze raz zaimportować tabele z pliku z danymi (tj. tu usunąć połączenia tabel z pliku programu bazy danych i raz jeszcze dokonać ich połączenia z danymi). Możliwe, że albo uszkodzony jest plik .mdb z danymi (chyba, że nie były zgłaszane ze strony NDAP jakiekolwiek błędy po wysłaniu danych), albo sam program iza.mdb. Nie sądzę, aby miało to związek ze strukturą sieci komputerowej i serwerem. U nas w AP również serwer plików wykorzystywany jest do regularnej pracy.
Problemem raczej mogłyby być kwestie stricte techniczne: karty sieciowe, przewody sieciowe (RJ45), routery, koncentratory, switche itp. Jeżeli podobne problemy nie występują w przypadku innych programów działających na linii klient<->serwer, lub baz, np. SEZAM (jak sądzę podobnie jest zorganizowany - plik z danymi na serwerze), to przyczyna na 99% tkwi w samej bazie IZA.
Proszę dać znać, czy cokolwiek z powyższego było brane pod uwagę. Jeśli nie - czy zadziałało. Może coś wykombinuję.
Pozdrawiam
Robert
APT O/W
-
Dziękuję za szybką reakcję.
Wypróbowaliśmy powyższe sposoby, przetestowaliśmy...
Niestety, nie zadziałało :(
Generalnie nie jest to problem uniemożliwiający pracę, ale mimo wszystko denerwujący. Pojawia się regularnie tylko przy drugim, czasem trzecim rekordzie. Niemniej od czasu do czasu daje znać o sobie częściej >:(
-
Czy przy wchodzeniu do bazy z serwera (tak, żeby zarówno plik danych, jak i plik programu były na jednym komputerze) pojawia się taki błąd? Jeśli tak, to faktycznie coś się uszkodziło. Pytanie tylko czy plik danych, czy program...
Podeślijcie plik z danymi do AP Włocławek (email podałem w wiadomości prywatnej). Spróbuję zamontować u siebie i zdam relacje.
Pogrzebałem jeszcze na stronach obcojęzycznych. Jest pewien alternatywny programik do kompaktowania: http://support.microsoft.com/kb/273956/PL/ ----> JETCOMP.exe
Jak widzę, działa tylko z bazami Access2000, ale nie powinien mieć problemu z plikiem danych. Oczywiście wszystko próbujemy mając kopię zapasową.
Tak czy siak z chęcią rzucę okiem na ów plik.
-
Na stronie archiwa.gov.pl ukazała sie informacja o planowanej w NDAP dyskusji wokół referatu p. H. Staszewskiej z AP Poznań pt. "Kierunki zmian w obowiązujących przepisach metodycznych w archiwach państwowych w kontekście wdrożenia zintegrowanego systemu informacji w archiwach państwowych - wybrane propozycje". Referat ten był przedmiotem zebrania naukowego w marcu 2008 r. w AP Poznań stąd też z oczywistych względów znam jego treść. Wykracza ona zdecydowanie poza wskazany w tytule kontekst. Znaczna część z postulowanych przez H. Staszewską zmian w przepisach metodycznych w archiwach państwowych powinna dokonać się nie dopiero przy okazji wdrażania Zosi, ile z racji przestrzegania narzuconych przez ogólną metodologię nauk najprostszych prawideł logiki. Autorzy różnego rodzaju przepisów składających się na instrumentarium metodyczne archiwistyki przez całe lata dość oszczędnie korzystali z owych prawideł. Można z dużą dozą prawdopodobieństwa przypuszczać, że wiecowo-referendalny sposób wypracowywania przepisów metodycznych w połączeniu z wyjątkową awersją do korzystania z zewnętrznych opinii eksperckich sprzyjał utrwalaniu się tego stanu rzeczy. Wydawać by się mogło, że nawet tak nieskomplikowana kwestia, jak opis fizyczny jednostek archiwalnych, nie powinna nastręczać większych problemów z przestrzeganiem elementarnych rygorów logiki .Tymczasem nawet na tym poziomie tak się niestety nie działo. Mam nadzieję, że postulowane przez H. Staszewską zmiany nie zostaną utopione w niekończących się dyskusjach w ramach komisji, podkomisji, zespołów, podzespołów itp. a archiwistyka polska wkroczy na ścieżkę pozwalającą jej opuscić pozycję jednego z głównych beneficjentów reguł logiki rozmytej wśród różnych dyscyplin wiedzy humanistycznej.
Mówi się, że młyny archiwalne mielą powoli. W tym przypadku to określenie nabiera nowego wymiaru. Od referatu Hanny Staszewskiej w którym postulowała modernizację przepisów metodycznych minęło 8 (OSIEM!!!) lat ??? . Miejmy nadzieję, że procedowanie prepisów w trybie wiecowo - referendalnym jest już za nami :)