🚀 go-pugleaf

Witam wszystkich

W swoich aplikacjach problem y2k rozwiazalem w ponizszy sposob:

Sub a_AfterUpdate ()
If Year(Me!a) = 1900 Then
  Me!a = DateAdd("yyyy", 100, Me!a)
End If
End Sub

Oczywiscie rozwiazanie dotyczy pola daty w formacie krotkim,
przy roku wprowadzanym czterocyfrowo problem nieistnieje.

PoZdro
Marek

Marek Kalmarczyk wrote:
> 
> Witam wszystkich
> 
> W swoich aplikacjach problem y2k rozwiazalem w ponizszy sposob:
> 
> Sub a_AfterUpdate ()
> If Year(Me!a) = 1900 Then
>   Me!a = DateAdd("yyyy", 100, Me!a)
> End If
> End Sub

przepraszam, a co z rokiem 2001 (i nastepnymi)??? Ponadto w tym
rozwiazaniu niemozliwe jest celowe wpisanie roku 1900, np. gdy aplikacja
wymaga wprowadzania dat "historycznych". Przypadek moze niezbyt czesty,
ale...

> Oczywiscie rozwiazanie dotyczy pola daty w formacie krotkim,
> przy roku wprowadzanym czterocyfrowo problem nieistnieje.

Oczywiscie. Dlatego moja propozycja po prostu wymusza za pomoca maski
wprowadzanie roku czterocyfrowo. Ma to swoje wady i zalety (osobiscie
uwazam - jednak wiekszosc zalet), ktore zreszta opisalem w mini-helpie
przykladu, o ktorym wspomnialem w poprzednim mailu.

Tak nawiasem, moj kolega wymyslil inne proste rozwiazanie, nieco
filozofia przypominajace Twoje. Mianowicie sprawdzac, czy wprowadzony
rok miesci sie w zakresie np. 1940-2040. Np. w tabeli, w polu
data/godzina, wprowadzic regule poprawnosci:

Between #01.01.1940# And #01.01.2040#

Wowczas jesli nawet user wklepie np. 1.1.01, Access zinterpretuje date
jako 1.1.1901, a regula nie dopusci do "przyjecia" takiego roku.

Jednak uwazam, ze takie "rozwiazanie" w i po roku 2000 bedzie tylko
dezorientowalo usera, bo i tak musi wprowadzic rok czterocyfrowo, aby
pole przyjelo rok 20xx. Ponadto daty musza miescic sie w zalozonym
okresie. Co prawda dla typowego np. wystawiania faktur moze byc
wystarczajace, ale po roku 2040 aplikacja w ogole przestanie dzialac...
(aczkolwiek wowczas nie bedzie to juz nasze zmartwienie ;-)

Pozdrawiam -
	Stanley

>> Sub a_AfterUpdate ()
>> If Year(Me!a) = 1900 Then
>>   Me!a = DateAdd("yyyy", 100, Me!a)
>> End If
>> End Sub
>
>przepraszam, a co z rokiem 2001 (i nastepnymi)???


Procedura tu przytoczona jest jedynie przykladem.
Zamiast "=1900" mozna wprawadzic "<1940" lub inny warunek.

>rozwiazaniu niemozliwe jest celowe wpisanie roku 1900, np. gdy aplikacja
>wymaga wprowadzania dat "historycznych".


Zgadam sie z toba w zupelnosci,
lecz dla aplikacji nie "historycznych", a wprowadzajacych
duza ilosc danych w postaci daty, wygodniejsze jest wprowadzanie
roku w postaci dwucyfrowej.

>Co prawda dla typowego np. wystawiania faktur moze byc
>wystarczajace, ale po roku 2040 aplikacja w ogole przestanie dzialac...
>(aczkolwiek wowczas nie bedzie to juz nasze zmartwienie ;-)


Tu masz calkowita racje, tez mam takie zdanie.

PoZdro
Marek

Marek Kalmarczyk wrote:
> 
> >> Sub a_AfterUpdate ()
> >> If Year(Me!a) = 1900 Then
> >>   Me!a = DateAdd("yyyy", 100, Me!a)
> >> End If
> >> End Sub
> >
> >przepraszam, a co z rokiem 2001 (i nastepnymi)???
> 
> Procedura tu przytoczona jest jedynie przykladem.
> Zamiast "=1900" mozna wprawadzic "<1940" lub inny warunek.

Niestety sprawa z dodawaniem stu lat nie jest taka prosta. W Twojej
propozycji pole daty nigdy nie przyjmie np. 29.02.00. Poniewaz wpisujac
w taki sposob, Access najpierw zinterpretuje te date jako 29.02.1900 - a
takiego dnia w historii nie bylo i wywali blad.
Po drugie. Access , takze 97, umozliwia  w miare "inteligentne"
wpisywanie dat, tzn. wpisujesz tylko dzien i miesiac (zreszta pisalem
juz o tym). Wowczas automatycznie dopisywany jest biezacy rok, odczytany
z daty systemowej. Wygodne przy wprowadzaniu bardzo "niehistorycznych"
dat, ale... Sprobuj przestawic na chwile w komputerze zegar systemowy na
y2k (lub y2k+1 czy podobny ;-) i wprowadzic w A2.0 np. 01.01. Wynikiem
bedzie 01.01.100 (!!!)  czyli 1 stycznia roku setnego :-o

Tak w ogole, takze probowalem kiedys wymyslic jakas cwana procedurke, w
stylu podobnym do Twojej. Jednak ze wzgledu na opisane wyzej problemy
dalem sobie spokoj. Dlatego "wymyslilem" stosowanie maski wprowadzania,
oraz rozwiazalem (tak mi sie przynajmniej wydaje ;-) w tym ukladzie
problem ewentualnej niezgodnosci maski z formatem daty ustawionym w
Panelu Sterowania. Nie twierdze, ze jest to rozwiazanie najlepsze i
jedynie sluszne, dlatego nadal jestem chetny przeslac je kazdemu
zainteresowanemu dla przetestowania i wyrazenia opinii.

> >rozwiazaniu niemozliwe jest celowe wpisanie roku 1900, np. gdy aplikacja
> >wymaga wprowadzania dat "historycznych".
> 
> Zgadam sie z toba w zupelnosci,
> lecz dla aplikacji nie "historycznych", a wprowadzajacych
> duza ilosc danych w postaci daty, wygodniejsze jest wprowadzanie
> roku w postaci dwucyfrowej.

Zgadzam sie. W ogole gdyby udalo sie wymyslec (moze Ci sie uda...) dla
tego typu aplikacji rozwiazanie dzialajace prawidlowo w przedziale np.
1980-2079 byloby bardzo fajnie (watpie, zeby ktos po y2079 uzywal
Accessa2.0 ;-) , lub musial wystawic np. fakture na 1979) .
"Prawidlowo" - mam tu na mysli mozliwosc wpisywania dat w kazdym
akceptowalnym przez Accessa formacie, prawidlowa interpretacje roku
dwucyfrowego z przelomu stuleci (raczej tysiacleci :-) tzn. np. 99=1999,
01=2001), wspolprace z formatem ustawionym Windows, czy data systemowa
komputera. Inaczej mowiac, tak jak dziala obecnie A2.0, z
wyeliminowaniem problemow, ktore wymienilem na poczatku.

Pozdrawiam -
	Stanley

Witam!

> Pomysl (nienowy) polega na stosowaniu w polach z data maski
> wprowadzania, wymuszajacej na userze ZAWSZE wprowadzanie roku
> czterocyfrowo. 

Nie wiem, czy szanowni grupowicze zastanawiali sie nad mozliwoscia "pojscia
dalej". Marzy mi sie aplikacja, ktora sprawdza zadana inna aplikacja
accessowa pod katem Y2K. Chodzi mi o np. przeanalizowania zapytan,
formularzy, raportow, kodu etc. i wychwycenia miejsc gdzie znajduja sie
maski, ciagi formatujace, wyrazenia operujace na datach etc. mogace
spowodowac ewentualne niescislosci po 2000. Wynikiem dzialania takiej
aplikacji powinien byc raport zawiarajacy lokalizacje i wyrazenie, ktore
jest potencjalnie podejrzane. W znaczy sposob ulatwi to przygotowanie
"review" aplikacji. Majac wszyskie miejsca do sprawdzenia, latwiej bedzie
je "odznaczyc" jak sprawdzone, poprawione... Najprostszy sposob moze
polegac na wyszukaniu ciagow typu Date, dd.mm.rr, rr.mm.dd, yy.mm.dd,
dd.mm.yy we wszystkich mozliwych miejscach (formaty pol, SQL, funkcje...) i
zaraportowanie. Jednak marzy mi sie odrobina inteligencji w tej aplikacji.
Jak ktos ma czas, jest zainteresowany prosze o kontakt. Niestety wolnego
czasu mam niewiele, bardzo chetnie podejmuje sie testowac lub w inny sposob
wspomagac tworzenie takiego projektu, szczegolnie dla wersji MSA2.0.

Z goracymi pozdrowieniami,
Tomasz Matejko

Tomasz Matejko wrote:
> 
> Witam!
> 
> > Pomysl (nienowy) polega na stosowaniu w polach z data maski
> > wprowadzania, wymuszajacej na userze ZAWSZE wprowadzanie roku
> > czterocyfrowo.
> 
> Nie wiem, czy szanowni grupowicze zastanawiali sie nad mozliwoscia "pojscia
> dalej".

Prawde rzeklszy nie bardzo... ;-)   (pisze za siebie ;-)

 Marzy mi sie aplikacja, ktora sprawdza zadana inna aplikacja
> accessowa pod katem Y2K. Chodzi mi o np. przeanalizowania zapytan,
> formularzy, raportow, kodu etc. i wychwycenia miejsc gdzie znajduja sie
> maski, ciagi formatujace, wyrazenia operujace na datach etc. mogace
> spowodowac ewentualne niescislosci po 2000. Wynikiem dzialania takiej
> aplikacji powinien byc raport zawiarajacy lokalizacje i wyrazenie, ktore
> jest potencjalnie podejrzane. W znaczy sposob ulatwi to przygotowanie
> "review" aplikacji. Majac wszyskie miejsca do sprawdzenia, latwiej bedzie
> je "odznaczyc" jak sprawdzone, poprawione... Najprostszy sposob moze
> polegac na wyszukaniu ciagow typu Date, dd.mm.rr, rr.mm.dd, yy.mm.dd,
> dd.mm.yy we wszystkich mozliwych miejscach (formaty pol, SQL, funkcje...) i
> zaraportowanie. Jednak marzy mi sie odrobina inteligencji w tej aplikacji.

Hmmmm... Pewnie na upartego mozna by takie cos uczynic, skoro w Accessie
jest dokumentator bazy, zrobiony zreszta w kodzie, jako biblioteka.
Jednak nie wiem, czy poniesiony naklad pracy bedzie odpowiedni do
otrzymanych efektow. Bo np. przykladowo uwazam, ze samo formatowanie
(dla wyswietlania) daty  w postaci skroconej, dwucyfrowej roku nie jest
niczym groznym. Rowniez tam, gdzie daty nie sa uzywane do zadnych
obliczen w koncu wszystko jedno, czy "gdzies w srodku" aplikacji jest
zapisane np. 01.01.1900 zamiast 01.01.2000 (oczywiscie jesli rok jest
wyswietlany dwucyfrowo). Bo przeciez user widzac np. na wydruku 01.01.00
raczej bedzie domniemywal, ze chodzi o y2000, a nie 1900 czy inny rok
zakonczony cyframi '00'.

Gorzej jest w przypadku przeciwnym - gdy wprowadzone daty sa uzywane
obliczen np. do chocby prostego zestawienia wystawionych dokumentow "za
okres od-do". Wowczas roznica miedzy wprowadzonym rokiem np. 1901 a 2001
jest chyba oczywista. Dlatego moje "rozwiazanie" dotyczy tylko tego
problemu (wprowadzania dat). Natomiast prawde rzeklszy dokladnie nie
wiem jakie sa ewentualne inne "zagrozenia" w Acc2.0 - pytalem zreszta
niezbyt dawno i jakos dotad bez odpowiedzi.

> Jak ktos ma czas, jest zainteresowany prosze o kontakt. Niestety wolnego
> czasu mam niewiele, bardzo chetnie podejmuje sie testowac lub w inny sposob
> wspomagac tworzenie takiego projektu, szczegolnie dla wersji MSA2.0.

Na beta-testera takze sie zapisuje, bo z wolnym czasem wiadomo jak jest
(raczej go nie ma ;-)

Pozdrawiam -
	Stanley

Stanley P wrote:
> 
> Tomasz Matejko wrote:
<...>
>  Marzy mi sie aplikacja, ktora sprawdza zadana inna aplikacja
> > accessowa pod katem Y2K. Chodzi mi o np. przeanalizowania zapytan,
> > formularzy, raportow, kodu etc. i wychwycenia miejsc gdzie znajduja 
<...>
> Dlatego moje "rozwiazanie" dotyczy tylko tego
> problemu (wprowadzania dat). Natomiast prawde rzeklszy dokladnie nie
> wiem jakie sa ewentualne inne "zagrozenia" w Acc2.0 - pytalem zreszta
> niezbyt dawno i jakos dotad bez odpowiedzi

Odnosnie 'innych zagrozen' - ponownie zajrzalem na strone (chyba bylem
tam kiedys, jeszcze gdy Acc2.0 nie byl ogloszony jako niezgodny z y2k):

http://www.microsoft.com/technet/topics/year2k/product/user_noncompliant.htm

Jest tam wyjasnione dlaczego A2.0 uznano jako niezgodny, oraz zalecane
metody obejscia problemu. Generalnie, o czym juz parokrotnie pisalem,
nie jest tak zle. Cala niezgodnosc polega na interpretacji dat, w
ktorych rok jest wpisywany dwucyfrowo, jako nalezacych do XX stulecia.
Natomiast zalecanym rozwiazaniem jest stosowanie maski wprowadzania
wymuszajacej rok czterocyfrowy, czyli dokladnie to co uczynilem w swojej
"propozycji", z tym ze moje rozwiazanie dodatkowo ustawia maske w
zaleznosci od formatu ustawionego w Ustawieniach Miedzynarodowych.

Tak nawiasem, podobny problem bedzie czekal aplikacje Accessa'97 - jesli
wtedy bedzie jeszcze go ktos uzywal - po roku 2029   ;-)

Pozdrawiam -
	Stanley