|
|
We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the program
interprets this date as 12/31/2089 instead of 12/31/1989 and warns that we
are providing a date outside of the fiscal period for the data. Is there a
compatibility mode or work-around so that the program will think we are in
the 1900's versus the 2000's?
|
|
"Blue Max" <mailrichard[ at ]msn.com> wrote in message
news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
[Quoted Text] > We are running an old MS-DOS program (Computer Associates AccPac Plus) in
> Windows Vista. However, this accounting program requires the user to log
> into the program with a date. The problem is that the log in uses a
> two-digit versus a 4-digit year. Since the data we are accessing is
> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the program
> interprets this date as 12/31/2089 instead of 12/31/1989 and warns that we
> are providing a date outside of the fiscal period for the data. Is there
> a compatibility mode or work-around so that the program will think we are
> in the 1900's versus the 2000's?
It looks like this program is grabbing the century from the system
clock. Being an old MS-DOS program it doesn't have the Y2K
correction algorithm for handling dates. Since it is a DOS program
the Vista date handling won't apply. One solution is to disconnect
that PC from the network and set the clock back to, say, 1999 when
running AccPac. Be aware that doing this could screw up your
Vista activation.
Another solution would be to dual boot with Win2000, if you
can find a copy, and set the system clock back each time you
boot to it. You would have to remember to set the correct date
before re-booting to Vista.
|
|
"Blue Max" <mailrichard[ at ]msn.com> wrote in message
news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
[Quoted Text] > We are running an old MS-DOS program (Computer Associates AccPac Plus) in
> Windows Vista. However, this accounting program requires the user to log
> into the program with a date. The problem is that the log in uses a
> two-digit versus a 4-digit year. Since the data we are accessing is
> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the program
> interprets this date as 12/31/2089 instead of 12/31/1989 and warns that we
> are providing a date outside of the fiscal period for the data. Is there
a
> compatibility mode or work-around so that the program will think we are in
> the 1900's versus the 2000's?
>
instead of entering "89" as the year
enter the full year "1989"
and it should (hopefully) display just "89"
|
|
"philo" <philo[ at ]privacy.net> wrote in message
news:unjLqsEQJHA.4760[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >
> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
> news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
>> We are running an old MS-DOS program (Computer Associates AccPac Plus) in
>> Windows Vista. However, this accounting program requires the user to log
>> into the program with a date. The problem is that the log in uses a
>> two-digit versus a 4-digit year. Since the data we are accessing is
>> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
>> program
>> interprets this date as 12/31/2089 instead of 12/31/1989 and warns that
>> we
>> are providing a date outside of the fiscal period for the data. Is there
> a
>> compatibility mode or work-around so that the program will think we are
>> in
>> the 1900's versus the 2000's?
>>
>
>
> instead of entering "89" as the year
>
> enter the full year "1989"
> and it should (hopefully) display just "89"
>
>
This is a log in with rigid fields, so the odds are that 1989 would
truncate to 19, with the resulting date of 2019. This program
was obviously released before Y2K was an issue for cross
century calculations.
The problem is that it appears to be using the system date for the
century info rather than a hard coded 19 prefix. This shows that
they allowed for the program to work in 20xx, but didn't consider
that users might want to use 19xx data. The OP could try 00, as
that might be close enough to the data range.
It is kind of weird that the log in requires a date relating to the data,
rather than the current date.
|
|
"Ian D" <taurus[ at ]nowhere.com> wrote in message
news:uWJbAqEQJHA.4008[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >
> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
> news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
>> We are running an old MS-DOS program (Computer Associates AccPac
>> Plus) in Windows Vista. However, this accounting program requires
>> the user to log into the program with a date. The problem is that
>> the log in uses a two-digit versus a 4-digit year. Since the data we
>> are accessing is pre-2000 (e.g. 1989) we enter 12/31/89, for example.
>> However, the program interprets this date as 12/31/2089 instead of
>> 12/31/1989 and warns that we are providing a date outside of the
>> fiscal period for the data. Is there a compatibility mode or
>> work-around so that the program will think we are in the 1900's
>> versus the 2000's?
>
> It looks like this program is grabbing the century from the system
> clock. Being an old MS-DOS program it doesn't have the Y2K
> correction algorithm for handling dates. Since it is a DOS program
> the Vista date handling won't apply. One solution is to disconnect
> that PC from the network and set the clock back to, say, 1999 when
> running AccPac. Be aware that doing this could screw up your
> Vista activation.
>
I regularly set the date on Vista PCs forward and back without issue, so
I doubt Vista will complain about activation. That said, I've never
gone back to a date in the last century so YMMV...
Another option is a virtual machine like VMWare. It allows setting the
system date of the virtual machine independently from the host machine.
DOSBox might as well, but I'm not familiar with it so I can't say.
Good luck!
--
Zaphod
Arthur: All my life I've had this strange feeling that there's something
big and sinister going on in the world.
Slartibartfast: No, that's perfectly normal paranoia. Everyone in the
universe gets that.
|
|
"Ian D" <taurus[ at ]nowhere.com> wrote in message
news:OKFeIdFQJHA.1908[ at ]TK2MSFTNGP04.phx.gbl...
[Quoted Text] > > "philo" <philo[ at ]privacy.net> wrote in message > news:unjLqsEQJHA.4760[ at ]TK2MSFTNGP02.phx.gbl... > > > > "Blue Max" <mailrichard[ at ]msn.com> wrote in message > > news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com... > >> We are running an old MS-DOS program (Computer Associates AccPac Plus)
> >> Windows Vista. However, this accounting program requires the user to
log
> >> into the program with a date. The problem is that the log in uses a
> >> two-digit versus a 4-digit year. Since the data we are accessing is
> >> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
> >> program
> >> interprets this date as 12/31/2089 instead of 12/31/1989 and warns that
> >> we
> >> are providing a date outside of the fiscal period for the data. Is
there
> > a
> >> compatibility mode or work-around so that the program will think we are
> >> in
> >> the 1900's versus the 2000's?
> >>
> >
> >
> > instead of entering "89" as the year
> >
> > enter the full year "1989"
> > and it should (hopefully) display just "89"
> >
> >
>
> This is a log in with rigid fields, so the odds are that 1989 would
> truncate to 19, with the resulting date of 2019. This program
> was obviously released before Y2K was an issue for cross
> century calculations.
>
> The problem is that it appears to be using the system date for the
> century info rather than a hard coded 19 prefix. This shows that
> they allowed for the program to work in 20xx, but didn't consider
> that users might want to use 19xx data. The OP could try 00, as
> that might be close enough to the data range.
>
> It is kind of weird that the log in requires a date relating to the data,
> rather than the current date.
>
>
You are probably right but I'd test it anyway
I recall that with dos, the field would accept four numerals for "date"
but simply display the last two.
I never had much of a problem when the year 2000 rolled in...
most of my machines handled it with no problem...
but one of them listed the date as 19100 !!!!
|
|
Does the program actually show 2089 or are you guessing? Many older DOS
programs would not allow forward dating and 89 would be greater than the
current 08.
"Blue Max" <mailrichard[ at ]msn.com> wrote in message
news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
[Quoted Text] > We are running an old MS-DOS program (Computer Associates AccPac Plus) in
> Windows Vista. However, this accounting program requires the user to log
> into the program with a date. The problem is that the log in uses a
> two-digit versus a 4-digit year. Since the data we are accessing is
> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the program
> interprets this date as 12/31/2089 instead of 12/31/1989 and warns that we
> are providing a date outside of the fiscal period for the data. Is there
> a compatibility mode or work-around so that the program will think we are
> in the 1900's versus the 2000's?
|
|
Thank you, Ian. Another oddity I have found since this posting is that
entering the year 90 (for 1990) displays properly as 1990, unlike the 89
(for 1989) that displays as 2089. Very interesting!
********************
"Ian D" <taurus[ at ]nowhere.com> wrote in message
news:uWJbAqEQJHA.4008[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >
> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
> news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
>> We are running an old MS-DOS program (Computer Associates AccPac Plus) in
>> Windows Vista. However, this accounting program requires the user to log
>> into the program with a date. The problem is that the log in uses a
>> two-digit versus a 4-digit year. Since the data we are accessing is
>> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
>> program interprets this date as 12/31/2089 instead of 12/31/1989 and
>> warns that we are providing a date outside of the fiscal period for the
>> data. Is there a compatibility mode or work-around so that the program
>> will think we are in the 1900's versus the 2000's?
>
> It looks like this program is grabbing the century from the system
> clock. Being an old MS-DOS program it doesn't have the Y2K
> correction algorithm for handling dates. Since it is a DOS program
> the Vista date handling won't apply. One solution is to disconnect
> that PC from the network and set the clock back to, say, 1999 when
> running AccPac. Be aware that doing this could screw up your
> Vista activation.
>
> Another solution would be to dual boot with Win2000, if you
> can find a copy, and set the system clock back each time you
> boot to it. You would have to remember to set the correct date
> before re-booting to Vista.
>
>
|
|
Thank you, Philo. Tried that, but it truncates to 19 (2019) as Ian
suspected.
*******************
"philo" <philo[ at ]privacy.net> wrote in message
news:unjLqsEQJHA.4760[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >
> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
> news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
>> We are running an old MS-DOS program (Computer Associates AccPac Plus) in
>> Windows Vista. However, this accounting program requires the user to log
>> into the program with a date. The problem is that the log in uses a
>> two-digit versus a 4-digit year. Since the data we are accessing is
>> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
>> program
>> interprets this date as 12/31/2089 instead of 12/31/1989 and warns that
>> we
>> are providing a date outside of the fiscal period for the data. Is there
> a
>> compatibility mode or work-around so that the program will think we are
>> in
>> the 1900's versus the 2000's?
>>
>
>
> instead of entering "89" as the year
>
> enter the full year "1989"
> and it should (hopefully) display just "89"
>
>
|
|
Hello, John. No, we are not guessing. The program, once it opens following
the log in, shows the complete 4-digit date. Moreover, we have observed
another interesting aspect. I have found, since the original posting, that
entering the year 90 (for 1990) displays properly as 1990, unlike the 89
(for 1989) that displays as 2089. Very interesting!
********************
"John Barnes" <JBarnes[ at ]email.com> wrote in message
news:%23Cqz8JfQJHA.4492[ at ]TK2MSFTNGP06.phx.gbl...
[Quoted Text] > Does the program actually show 2089 or are you guessing? Many older DOS
> programs would not allow forward dating and 89 would be greater than the
> current 08.
>
>
> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
> news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
>> We are running an old MS-DOS program (Computer Associates AccPac Plus) in
>> Windows Vista. However, this accounting program requires the user to log
>> into the program with a date. The problem is that the log in uses a
>> two-digit versus a 4-digit year. Since the data we are accessing is
>> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
>> program interprets this date as 12/31/2089 instead of 12/31/1989 and
>> warns that we are providing a date outside of the fiscal period for the
>> data. Is there a compatibility mode or work-around so that the program
>> will think we are in the 1900's versus the 2000's?
>
|
|
"Blue Max" <mailrichard[ at ]msn.com> wrote in message
news:e7suzxcRJHA.4608[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > "Ian D" <taurus[ at ]nowhere.com> wrote in message
> news:uWJbAqEQJHA.4008[ at ]TK2MSFTNGP02.phx.gbl...
>>
>> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
>> news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
>>> We are running an old MS-DOS program (Computer Associates AccPac
>>> Plus) in Windows Vista. However, this accounting program requires
>>> the user to log into the program with a date. The problem is that
>>> the log in uses a two-digit versus a 4-digit year. Since the data
>>> we are accessing is pre-2000 (e.g. 1989) we enter 12/31/89, for
>>> example. However, the program interprets this date as 12/31/2089
>>> instead of 12/31/1989 and warns that we are providing a date outside
>>> of the fiscal period for the data. Is there a compatibility mode or
>>> work-around so that the program will think we are in the 1900's
>>> versus the 2000's?
>>
>> It looks like this program is grabbing the century from the system
>> clock. Being an old MS-DOS program it doesn't have the Y2K
>> correction algorithm for handling dates. Since it is a DOS program
>> the Vista date handling won't apply. One solution is to disconnect
>> that PC from the network and set the clock back to, say, 1999 when
>> running AccPac. Be aware that doing this could screw up your
>> Vista activation.
>>
>> Another solution would be to dual boot with Win2000, if you
>> can find a copy, and set the system clock back each time you
>> boot to it. You would have to remember to set the correct date
>> before re-booting to Vista.
>>
> Thank you, Ian. Another oddity I have found since this posting is
> that entering the year 90 (for 1990) displays properly as 1990, unlike
> the 89 (for 1989) that displays as 2089. Very interesting!
>
Rather than grabbing the century from the system clock, it looks like
the program uses a "pivot date" of 90 - that is, anything from 90 - 99
is 20th century and anything 00 - 89 is 21st century. The program
wasn't originally written / released in 1990 by any chance, was it?
--
Zaphod
No matter where you go, there you are!
|
|
"Zaphod Beeblebrox" wrote:
[Quoted Text] > "Blue Max" <mailrichard[ at ]msn.com> wrote:
>> "Ian D" <taurus[ at ]nowhere.com> wrote:
>>> "Blue Max" <mailrichard[ at ]msn.com> wrote:
>>>> We are running an old MS-DOS program (Computer Associates AccPac Plus)
>>>> in Windows Vista. However, this accounting program requires the user
>>>> to log into the program with a date. The problem is that the log in
>>>> uses a two-digit versus a 4-digit year. Since the data we are
>>>> accessing is pre-2000 (e.g. 1989) we enter 12/31/89, for example.
>>>> However, the program interprets this date as 12/31/2089 instead of
>>>> 12/31/1989 and warns that we are providing a date outside of the fiscal
>>>> period for the data. Is there a compatibility mode or work-around so
>>>> that the program will think we are in the 1900's versus the 2000's?
>>> It looks like this program is grabbing the century from the system
>>> clock. Being an old MS-DOS program it doesn't have the Y2K
>>> correction algorithm for handling dates. Since it is a DOS program
>>> the Vista date handling won't apply.
>> Thank you, Ian. Another oddity I have found since this posting is that
>> entering the year 90 (for 1990) displays properly as 1990, unlike the 89
>> (for 1989) that displays as 2089. Very interesting!
> Rather than grabbing the century from the system clock, it looks like the
> program uses a "pivot date" of 90 - that is, anything from 90 - 99 is 20th
> century and anything 00 - 89 is 21st century. The program wasn't
> originally written / released in 1990 by any chance, was it?
I think that the OP is running ACCPAC version 6. Version 5 and below
assumed that all dates were 19xx; version 6 splits the centuries at 1989/90.
Presumably the intent was to preserve the batch input format between
versions; it uses a 2-digit date. It's not particularly well documented (a
characterization that covers much of the ACCPAC product...) but in version 6
the date is windowed to support dates from 1990 through 2089. You can see
this by attempting to print batch reports between dates of 12/31/89 through
12/31/99 (fails; "start date not prior to end date") and 01/01/90 through
12/31/99 (works). V6 carries a 1993 copyright date.
The places where "today's date" is used it acts on 2-digit years. As far as
I can tell it doesn't make any use of the century from the hardware clock
except for the date display in the page and screen headers.
If the OP really does need to work with the 1989 data and can't find a copy
of ACCPAC version 5 (IIRC version 5 introduced several features missing in
earlier versions, and uses a different input and report format compared to
v4) then it might be possible to bludgeon it into working by re-editing the
fiscal calendar (HOUSEKEEPING -> EDIT COMPANY PROFILE) on he off chance that
it would make "89" valid.
On the other hand, it may be that year "89" has a boundary case problem and
can't be made to work. If the 1989 transactions are available as batch
input files, you could manually edit each line to window them to another
year (say, "39" for 2039, a 50-year bias), process them, then interpret the
reports by subtracting 50 years from any date. Kludgy, but if this is a
one-time (or at least very infrequent) process it might be easier than some
other options.
Then there's the obvious suggestion that the OP (or his employer, or
customer) just bite the bullet and scrap ACCPAC in favor of a more recent
product. Maybe even ACCPAC for Windows (which I've never used).
BTW: my experience is exclusively with the GL component, but presumably the
others (AR, AP, etc.) share the same date behavior.
Joe Morris
|
|
When they hardcoded the program they picked a cutoff year. In this case
anything less than 90 is expanded to 20xx as they didn't expect earlier
dates to be used and this would be usefull until 2089. Anything 90 or
greater would use 19 to get thru the end of the century. They should have
given more room backwards as any coder should have known the program would
not be used more than 30-40 years.
"Blue Max" <mailrichard[ at ]msn.com> wrote in message
news:O$PE8zcRJHA.1160[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] > Hello, John. No, we are not guessing. The program, once it opens
> following the log in, shows the complete 4-digit date. Moreover, we have
> observed another interesting aspect. I have found, since the original
> posting, that entering the year 90 (for 1990) displays properly as 1990,
> unlike the 89 (for 1989) that displays as 2089. Very interesting!
>
> ********************
> "John Barnes" <JBarnes[ at ]email.com> wrote in message
> news:%23Cqz8JfQJHA.4492[ at ]TK2MSFTNGP06.phx.gbl...
>> Does the program actually show 2089 or are you guessing? Many older DOS
>> programs would not allow forward dating and 89 would be greater than the
>> current 08.
>>
>>
>> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
>> news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
>>> We are running an old MS-DOS program (Computer Associates AccPac Plus)
>>> in Windows Vista. However, this accounting program requires the user to
>>> log into the program with a date. The problem is that the log in uses a
>>> two-digit versus a 4-digit year. Since the data we are accessing is
>>> pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
>>> program interprets this date as 12/31/2089 instead of 12/31/1989 and
>>> warns that we are providing a date outside of the fiscal period for the
>>> data. Is there a compatibility mode or work-around so that the program
>>> will think we are in the 1900's versus the 2000's?
>>
>
|
|
Thanks, Joe, I think you have clearly explained the dilemma. It sounds like
you have some good background in AccPac. While the described problem is a
concern, it is not a major concern. We occasionally need to access older
data and the anomaly arose during one of those excursions into the old data.
As to an upgrade, we did that long ago! We eventually became extremely
displeased with Computer Associates (then the publisher), the increasing
cost of AccPac, the increasing cost of support, and the limited flexibility
of the program. As such, we invested in Peachtree Premium Accounting
(originally Peachtree Complete Accounting for about $250.00) and have been
extremely pleased with that product, except for the escalating cost of the
program. For some reason, publishers can't resist the tempation of
continually increasing the cost once they have an established user base.
Thanks for the help.
*********************************
"Joe Morris" <j.c.morris[ at ]verizon.net> wrote in message
news:gfl5pg02qbd[ at ]news2.newsguy.com...
[Quoted Text] > "Zaphod Beeblebrox" wrote:
>> "Blue Max" <mailrichard[ at ]msn.com> wrote:
>>> "Ian D" <taurus[ at ]nowhere.com> wrote:
>>>> "Blue Max" <mailrichard[ at ]msn.com> wrote:
>
>>>>> We are running an old MS-DOS program (Computer Associates AccPac Plus)
>>>>> in Windows Vista. However, this accounting program requires the user
>>>>> to log into the program with a date. The problem is that the log in
>>>>> uses a two-digit versus a 4-digit year. Since the data we are
>>>>> accessing is pre-2000 (e.g. 1989) we enter 12/31/89, for example.
>>>>> However, the program interprets this date as 12/31/2089 instead of
>>>>> 12/31/1989 and warns that we are providing a date outside of the
>>>>> fiscal period for the data. Is there a compatibility mode or
>>>>> work-around so that the program will think we are in the 1900's versus
>>>>> the 2000's?
>
>>>> It looks like this program is grabbing the century from the system
>>>> clock. Being an old MS-DOS program it doesn't have the Y2K
>>>> correction algorithm for handling dates. Since it is a DOS program
>>>> the Vista date handling won't apply.
>
>>> Thank you, Ian. Another oddity I have found since this posting is that
>>> entering the year 90 (for 1990) displays properly as 1990, unlike the 89
>>> (for 1989) that displays as 2089. Very interesting!
>
>> Rather than grabbing the century from the system clock, it looks like the
>> program uses a "pivot date" of 90 - that is, anything from 90 - 99 is
>> 20th century and anything 00 - 89 is 21st century. The program wasn't
>> originally written / released in 1990 by any chance, was it?
>
>
> I think that the OP is running ACCPAC version 6. Version 5 and below
> assumed that all dates were 19xx; version 6 splits the centuries at
> 1989/90. Presumably the intent was to preserve the batch input format
> between versions; it uses a 2-digit date. It's not particularly well
> documented (a characterization that covers much of the ACCPAC product...)
> but in version 6 the date is windowed to support dates from 1990 through
> 2089. You can see this by attempting to print batch reports between dates
> of 12/31/89 through 12/31/99 (fails; "start date not prior to end date")
> and 01/01/90 through 12/31/99 (works). V6 carries a 1993 copyright date.
>
> The places where "today's date" is used it acts on 2-digit years. As far
> as I can tell it doesn't make any use of the century from the hardware
> clock except for the date display in the page and screen headers.
>
> If the OP really does need to work with the 1989 data and can't find a
> copy of ACCPAC version 5 (IIRC version 5 introduced several features
> missing in earlier versions, and uses a different input and report format
> compared to v4) then it might be possible to bludgeon it into working by
> re-editing the fiscal calendar (HOUSEKEEPING -> EDIT COMPANY PROFILE) on
> he off chance that it would make "89" valid.
>
> On the other hand, it may be that year "89" has a boundary case problem
> and can't be made to work. If the 1989 transactions are available as
> batch input files, you could manually edit each line to window them to
> another year (say, "39" for 2039, a 50-year bias), process them, then
> interpret the reports by subtracting 50 years from any date. Kludgy, but
> if this is a one-time (or at least very infrequent) process it might be
> easier than some other options.
>
> Then there's the obvious suggestion that the OP (or his employer, or
> customer) just bite the bullet and scrap ACCPAC in favor of a more recent
> product. Maybe even ACCPAC for Windows (which I've never used).
>
> BTW: my experience is exclusively with the GL component, but presumably
> the others (AR, AP, etc.) share the same date behavior.
>
> Joe Morris
>
|
|
Thanks, John. According to others also, this appears to be the case.
Certainly agree with your perception that the cut-off window was poor and
should have favored earlier pre-existing data over the unlikely creation of
data in this package 50 years from now.
****************
"John Barnes" <JBarnes[ at ]email.com> wrote in message
news:uNmmBo3RJHA.1172[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > When they hardcoded the program they picked a cutoff year. In this case
> anything less than 90 is expanded to 20xx as they didn't expect earlier
> dates to be used and this would be usefull until 2089. Anything 90 or
> greater would use 19 to get thru the end of the century. They should have
> given more room backwards as any coder should have known the program would
> not be used more than 30-40 years.
>
> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
> news:O$PE8zcRJHA.1160[ at ]TK2MSFTNGP02.phx.gbl...
>> Hello, John. No, we are not guessing. The program, once it opens
>> following the log in, shows the complete 4-digit date. Moreover, we have
>> observed another interesting aspect. I have found, since the original
>> posting, that entering the year 90 (for 1990) displays properly as 1990,
>> unlike the 89 (for 1989) that displays as 2089. Very interesting!
>>
>> ********************
>> "John Barnes" <JBarnes[ at ]email.com> wrote in message
>> news:%23Cqz8JfQJHA.4492[ at ]TK2MSFTNGP06.phx.gbl...
>>> Does the program actually show 2089 or are you guessing? Many older DOS
>>> programs would not allow forward dating and 89 would be greater than the
>>> current 08.
>>>
>>>
>>> "Blue Max" <mailrichard[ at ]msn.com> wrote in message
>>> news:3BBD8EB1-5854-48FD-A0B1-A52A60C9D980[ at ]microsoft.com...
>>>> We are running an old MS-DOS program (Computer Associates AccPac Plus)
>>>> in Windows Vista. However, this accounting program requires the user
>>>> to log into the program with a date. The problem is that the log in
>>>> uses a two-digit versus a 4-digit year. Since the data we are
>>>> accessing is pre-2000 (e.g. 1989) we enter 12/31/89, for example.
>>>> However, the program interprets this date as 12/31/2089 instead of
>>>> 12/31/1989 and warns that we are providing a date outside of the fiscal
>>>> period for the data. Is there a compatibility mode or work-around so
>>>> that the program will think we are in the 1900's versus the 2000's?
>>>
>>
>
|
|
|