Y2K Compliance in VB v3 
Author Message
 Y2K Compliance in VB v3

I have a VB v3 application that stores all dates as a 10 byte string in the
yyyyy-mm-dd format.  I have been advised that VB v3 will still prevent the
application from being y2k compliant.

Any comments will be appreciated.

Thanks,

Phil



Sun, 08 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3
Phil,

Y2K compliance is not a "badge" you apply for.  It merely says that your
application will run (correctly!) on 1 Jan 2000.  I have some difficulty in
understanding how a compiler/interpreter can fail to work on 1/1/2000.

If a programmer has stored dates yy-mm-dd then the program will likely
fail - whether written in VB3, VB6 or assembler.  Your date structure will
recognise the turn of the century.  VB3's internal date structures will (I'm
fairly certain - but can't test, long since upgraded) recognise year 2000
correctly.  Whether DOS is Y2K compliant is a more interesting question, or
for that matter Windows 3.1.  I have no information on that subject.

To test Y2K compliance on a stand-alone application why don't you change the
system date to 1/1/2000 and see what happens!

BTW slightly excessive cross-posting don't you think?

Peter

Quote:

>I have a VB v3 application that stores all dates as a 10 byte string in the
>yyyyy-mm-dd format.  I have been advised that VB v3 will still prevent the
>application from being y2k compliant.

>Any comments will be appreciated.

>Thanks,

>Phil




Sun, 08 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3
Not sure what THEY are talking about.  The Y2K problem is a date problem!
If your Database holds the date with 4 digit year, all of your program
processes as 4 digit year and the operating system recognizes 4 digit years
and Feb 29, 2000 then....  I think you should be Y2K OK????

Let me know if I'm wrong

Richard Wittmann



Quote:
> I have a VB v3 application that stores all dates as a 10 byte string in
the
> yyyyy-mm-dd format.  I have been advised that VB v3 will still prevent
the
> application from being y2k compliant.

> Any comments will be appreciated.

> Thanks,

> Phil




Sun, 08 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3
: Phil,

: Y2K compliance is not a "badge" you apply for.  It merely says that your
: application will run (correctly!) on 1 Jan 2000.  I have some difficulty in
: understanding how a compiler/interpreter can fail to work on 1/1/2000.

Typically compilers are smart enough only to rebuild modules that have
been changed since the last build. That can go out the window.



Sun, 08 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3
Harlan,

Fair point!  Although compile times in VB5 don't suggest that this compiler
has that level of "smartness"!.

Peter

Quote:


>: Phil,

>: Y2K compliance is not a "badge" you apply for.  It merely says that your
>: application will run (correctly!) on 1 Jan 2000.  I have some difficulty
in
>: understanding how a compiler/interpreter can fail to work on 1/1/2000.

>Typically compilers are smart enough only to rebuild modules that have
>been changed since the last build. That can go out the window.



Sun, 08 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3
Not to mention that a non-Y2K compliant compiler will generate code which
does not process dates properly or build applications that will not work
properly using dates after 01-JAN-2000.

Quote:


>: Phil,

>: Y2K compliance is not a "badge" you apply for.  It merely says that your
>: application will run (correctly!) on 1 Jan 2000.  I have some difficulty
in
>: understanding how a compiler/interpreter can fail to work on 1/1/2000.

>Typically compilers are smart enough only to rebuild modules that have
>been changed since the last build. That can go out the window.



Sun, 08 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3
Bob,

Harlan's point is perfectly valid (although easily worked around - rebuild
all in VC5 for example).  It does not appear to apply to VB however.

I suppose it is conceivable that there are compilers out there that have
intrinsic date classes in them that don't recognise year 2000.  VB is not
such a compiler (and this is a VB forum and the original post referred to
VB3!).

Perhaps you have some specific examples in mind?

I think a little bit more common-sense and a bit less hysteria would
probably help businesses focus more effectively on Y2K problems.  The bulk
of the problems appear to relate to situations where data is stored (not
processed) in some variant of dd/mm/yy format.  An examination of data
storage formats would seem to me a more effective approach than looking for
Y2K-badged compilers!  After all if a VB5 program were to read a date
(stored as dd/mm/yy) and processed it using the flawed code of:

    ThisDate& =
DateSerial(1900+right$(DateStr$,2),mid$(DateStr$,4,2),Left$(DateStr$,2))

it will generate 1-Jan-1900 if run on 1st Jan 2000.

The problem is not the compiler, the problem is the program logic, flowing
from the data storage mistake.

As it happens VB5 will process DateSerial(0,1,1) as 1-Jan-2000 and ditto
datevalue("1/1/0").  Don't help the problem above though.  I presume you
would say that VB5 was Y2K compliant however!

Peter

Quote:

>Not to mention that a non-Y2K compliant compiler will generate code which
>does not process dates properly or build applications that will not work
>properly using dates after 01-JAN-2000.



>>: Phil,

>>: Y2K compliance is not a "badge" you apply for.  It merely says that your
>>: application will run (correctly!) on 1 Jan 2000.  I have some difficulty
>in
>>: understanding how a compiler/interpreter can fail to work on 1/1/2000.

>>Typically compilers are smart enough only to rebuild modules that have
>>been changed since the last build. That can go out the window.



Mon, 09 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3

Y2K compliance can be difficult to determine. It can fail due to non-compliance of

    O/S component
    Harware driver
    Bios

are a few common causes.

The only 100% way to make sure that the system is Y2K compliant is to isolate the environment.
    a.. Run all the system test cases. Save the results.
    b.. Change the environment date.
    c.. Run all the system test cases. Save the results.
    d.. Compare the results.
    e.. Check the results.
Sorry, this may not be of any help.

Quote:

>I have a VB v3 application that stores all dates as a 10 byte string in the
>yyyyy-mm-dd format.  I have been advised that VB v3 will still prevent the
>application from being y2k compliant.

>Any comments will be appreciated.

>Thanks,

>Phil




Tue, 10 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3


stores all dates as a 10 byte string in the
Quote:
>yyyyy-mm-dd format.  I have been advised that VB v3 will still prevent
the
>application from being y2k compliant.

>Any comments will be appreciated.

>Thanks,

>Phil


        ".... I have been advised that VB v3 will still prevent the
application from being y2k compliant..."

    That's Bullshit some jealous individual blowhard is just trying to
knock your{*filter*} in the dirt.
I don't think You can buy a peice of hardware or a software dev. program
today that is NOT Y2K compliant.

Quote:


>  >Y2K compliance can be difficult to determine. It can fail due to
> non-compliance of >    O/S component
> Can anyone show me an O/S that you could buy today that is NOT Y2K
> compliant? I don't think so
>  >    Harware driver
> .... hardware drivers usualy come with hardware or are written for a
> particular peice of hardware....again is it possible to buy a peice of
> Hardware today that is NOT Y2K compliant?
> what kind of hardware would care about the date anyway? to me hardware
> means printer, scanner, mouse, display, drives, modems, IR scanners, I
> can't think of a peice of EXTERNAL hardware that would ever care about
> the date...??? ....Now internal hardware is another question like the
> motherboard or CPU, but again, can You possibly buy some today that
> aint???

> >    Bios
>                 .....Bios is usually but not always firmware is the
> form of ROM chips that come attached to the hardware....or software
> written for  a peice of wardware and supplied with it or by the
> MFGR....which brings back the same question/answere ..... can You
> possibly buy some today that aint???
>   >are a few common causes. >The only 100% way to make sure that the
> system is Y2K compliant is to isolate the environment.

>    * Run all the system test cases. Save the results.
>    * Change the environment date.
>    * Run all the system test cases. Save the results.
>    * Compare the results.
>    * Check the results.

  I am maybe a sceptic who thinks that WAY WAY WAY to much FEAR and HYPE
are being propagated around this Y2K date thing.....I have 3 1980 PC-XTs
in the other room and they are all Y2K compliant..... you tell them it's
2010 and it tells you it's 2010 no problem, even writes on FAT that its
2010. These are 20 year old machines and they can handle dates past
2000.... every machine made since then can do it.... It's really the
softwares job(programmers job)  to know how to handle the date.

My real problem with all the SKY is FALLING {*filter*}is that ONLY programs
that NEED and USE the DATE in the PROCESS will have to worry about the
date.... the elevator has no idea what da it is and will go up and down
just like normal.... you r car doesn't care what the date is.... what
season maybe,  but as long as the whethers good, the car will run just
fine provided nothing else is wrong with it.

Now Mortgage amortization programs, programs that calculate interest
over time, stuff like that needs to keep track of the date.....ANYthing
you buy today ...I just gotta belive is going ot be capable of handling
the date.

in the WORST case scenario..... on 1-1-2000, a lot of  financial
programs might produce a bunch of defective data based on bas data as
it's input.
Any intelligent programmer/analyst can look at the data and say "Well it
was multiplied by x insead of y," and very easily fix it by dividing by
x to get the original data back and then multiplying by y to get the
right data, ..
.....and then even with non compliant software teh problem will be
solved for another hundred years.... of course by then hopefull
everything will be compliant.

I think it's all being blown way out of proportion by software companies
and consultants  to takeadvantage of a once in a century opportunity to
get rich off of the  less knowledgeable public, and corporate clients by
selling them a bunch of new software and consultant services when the
problem isn't nearly as bad as they say it is.

Like going to the doctor with a cold and him sending you to a bunch of
specialists so they can all get some money out of you.

Speaking of which..... I also wonder if computer viruses weren't
invented by anti viral programmers to create a need for their product?

Nah!.......and MicroSoft would Never pay people off to help crush
Netscape either....they'd certainly never have put a bug in W3.1 to
crash the system if you weren't running MS-DOS.... Those few bytes of
encrypted code must be for something else.... "to make it Y2KC that's
it!, yea that's the ticket"

just wake me up when it all blows over.

            Joe



Fri, 13 Apr 2001 03:00:00 GMT  
 Y2K Compliance in VB v3
<date>
Quote:
>My real problem with all the SKY is FALLING {*filter*}is that ONLY programs
>that NEED and USE the DATE in the PROCESS will have to worry about the
>date.... the elevator has no idea what da it is and will go up and down
>just like normal.... you r car doesn't care what the date is.... what
>season maybe,  but as long as the whethers good, the car will run just
>fine provided nothing else is wrong with it.

<cut>

On the whole, I agree that the problem is probably being way overblown but
even the elevator may cause trouble.  In the building I work in, for
example, the elevators are controlled by a computer system.  Monday-Friday
they open and allow free access at 7AM but on Saturday & Sunday you need an
access card.  If the system decides that the day is a weekend because it was
in 1900 then we are going to have a lot of problems.  The same is true for
all the environment control systems in the building.  That certainly isn't
life-threatening but only meant as an example of unexpected consequences
that is going to cause a lot of trouble.  If those troubles affect
police/fire/medical response systems then things can snowball.  If they
affect financial transfer systems they could cause a lot of upset and that
again can snowball.

While I do not expect the end of the world, I do expect a great deal of
disruption for a while.



Fri, 13 Apr 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Y2K Compliance in VB v3

2. Y2K Compliance in VB v3

3. Y2K Compliance in VB v3

4. Y2K tool to assess,remediate visual basic tool for Y2k compliance

5. VB 5 And VB 6 Y2K Compliance Statments ?

6. Year2K Compliance of Microsoft Basic PDS 7.1 and Consulting Firms specializing in Y2K and PDS 7.1

7. VB5 Y2K Compliance

8. VB4 Y2K Compliance

9. crystal report Y2k compliance

10. VBA 5.0 - Y2K compliance

11. Y2K compliance of VB4...

12. To Y2K or not to Y2K: A New Y2K Survey

 

 
Powered by phpBB® Forum Software