Addsum web site and general info

Postings here will focus mainly on Advanced Accounting software updates, tips, and related topics. They will also include general comments relating to troubleshooting PC/Windows/network problems and may also include reference to our other software products and projects including any of our various utilities, or to the TAS Premier programming language. We considered setting up separate blogs for different topics so that users/others could subscribe to topics mostly aligned with their interests, but decided that it would be better to keep things simple since some topics cross over into others. We would nonetheless welcome your feedback/input in this regard. Our web site URL is Call us at 800-648-6258 or 801-277-9240. We also maintain so that older Business Tools users in particular have a greater chance to find us.


We highly recommend that accounting software users "follow" this blog via e-mail (enter your address and click on Submit below) or subscribe to a feed (see also below) as a way to keep current on the latest updates and accounting software news and information. You may also want to whitelist this e-mail address:

Follow by e-mail

Wednesday, March 13, 2019

Btrieve status code 46

Your users may occasionally experience a Btrieve engine (which here includes the Pervasive and now Actian engines sometimes also referred to as PSQL) status code 46 which indicates that access to a given file ("table") is denied leading to the inability of the software to write to that file.   There are some straightforward reasons for this but also several that are non-intuitive.

A file that is marked as read only whether via user rights or because it was dragged/dropped from media that is read only is the most obvious cause, although usually isn't the cause.  Ensure that the user has both read/write rights (and since in some versions temporary files are created, the user needs delete rights to data folders as well).   Most commonly this happens when a new client PC is added to a network and the user's rights are insufficient.

File forced to be read only and the result when that file is attempted to be written to

Another issue could be an older formatted Btrieve file.  As users move forward to newer versions of the software and deploy newer Pervasive versions, some of their files may be in an older format that starting with Pervasive 9.x (now considered legacy since the latest version currently is v13 released in 2017), Btrieve 5.x and older files can be read but not written to until they are rebuilt (or "reindexed") into a newer format (6.x or above but 9.5 is the usual standard even with later releases).   A rebuild utility is provided with the Actian/Pervasive engines and is the best way to resolve.  Our reindex program, as originally developed by Business Tools, can globally identify the format level of a user's files in a given company.

Older format causing status code 46 format determined via a BUTIL -STAT

Another possibility is the use of an owner name where an incorrect owner name is passed when the file is open.   While the underlying programming language supports owner names, owner names are normally not used in Advanced Accounting programs, and so this cause can normally be ruled out.

A mixture of Btrieve 6.15 and Pervasive/PSQL engines can lead to a status code 46.   The two engines cannot be used to access the same data files simultaneously.    Different PSQL various normally can be used safely together although it is best that all PC's use the same version.

The most difficult situation involves outside applications or processes that may be scanning,  copying or indexing the data files. We previously made brief mention of status code 46 issues with respect to online or live database backups and these are the the most common cause.

This issue has been known for sometime now but can be very difficult to troubleshoot, and it can lead to significant loss of data should it strike.  Typically we have something like four or five support calls every year where the end user has lost data as a result of a status code 46 issue, whether observed as such or not.  

The peculiarity relates to how the Btrieve API reacts to a file that is being copied or scanned and when it then tries to open that file while no other instances of that file are open by anyone.   If the file that is being copied or scanned was already open by the Btrieve engine on some client/workstation prior to initiation of the copying or scanning, there is no issue.   But if no user has the file open, and the copy or scan begins, and then the file is opened through say the accounting sofware, the Btrieve/Pervasive engine opens the file in a read only mode, and  that is not easily detectable.  Only later when typically a record is attempted to be saved to that file will the 46 result and usually in the middle of a posting process.  The user at that point is able to click on OK and continue.  And continue.  And each time OK is pressed, a record in that file is effectively "lost."  And once this starts to happen, a domino effect occurs to other users who try to access the file and write to it, and the 46 status remains until all instances of the file are closed (even though the copying or scanning process may have long since completed).

It is larger files that take longer to copy or scan that are the most vulnerable, and these often are also some of the more important files.  If all files were all opened all of the time, this kind of status code 46 could never  happen (placing all files in continuous operations mode avoids the problem for backup purposes, but places a heavy overhead on a system).  Keeping all of the files open all of the time however is normally very inefficient and isn't what happens in a typical Advanced Accounting program.  Files instead that are needed in a given program option are instead opened at the beginning of that option and they are automatically closed when that individually selected program option ends (or can be closed earlier programmatically).  This normal internal structure combined wiht the behavior of the Btrieve API can, albeit under somewhat rare circumstances,  lead to situations where no files are opened by anyone and then suddenly an online backup or anti-virus scan of some kind starts just before a user than starts a program than opens that same file, and it if is a file that is later written to or deleted (such as in a posting program), status code 46's can result.

Anti-virus software has been suspected of triggering this issue.  Your data file folders should be excluded from real time anti-virus scanning (data files cannot become infected, and  this is something that is desirable in any event because it will improve performance).  In our experience, the 46's have always been tied to some sort of backup or copy operation that was in progress when a user then unknowingly selected a posting program that opened the same file that was being copied, with no prior instances of the file having been opened by a Btrieve engine.

For one user that was having a problem when copying data files off late in the afternoon to laptops and another that was having nighttime backups taking longer and longer and were still running in the early morning hours (including 5.1 versions in fact), we added some logic when records were being saved to detect this issue.  But that doesn't prevent the problem in the first place and further when it happens, the user can't usually easily resolve the problem on their own.  Therefore we have recently implemented some new logic where we test the most exposed/larger files that are going to be written to in advance to detect if the file is being copied or is being accessed in some manner from outside of the software (and if the copy started before the file was opened by any accounting software user).   We have implemented this newer logic in the SO-G posting program in the latest versions of Advanced Accounting, and will be adding it to others. 

Note that when posting sales orders on the fly, the AR invoice header file (BKARHINV) is already open in Advanced Accounting because it is needed to check for previously assigned invoice numbers.  So when that sales order is then posted right after printing or a print preview, a status code 46 would never result but rather only when posting sales orders in a batch (normally a good thing).  The general ledger transaction file (BKGLTRAN) in either case however would still be vulnerable and that is a file that we also "pre-check."

How can you avoid status code 46's in the situation as last discussed above? 

 (1) Exclude data files from being scanned in real-time.   As noted, it can actually be helpful to have other users utilizing the software keep certain files open during posting processes that can, counterintuitively, help with  this access denied status code (although they can create other problems by locking customer or inventory location records).

(2)  Use of continuous operations mode can also help to avoid the issue.  But most importantly, ensure that scheduled backups are taking place well outside of normal operation times and monitor them to ensure they don't start to creep into the early morning hours.

Note: if you are making a manual backup copy of a file on a system that is live and that is fairly large in size and will take more than a few seconds to copy, it is actually safest to first open that file (either in maintain database or in some program that you know opens it)  prior to making the copy.  Otherwise your file copy request, if the file is large enough, could cause a live user to experience a status code 46.

Thursday, February 28, 2019

Screen ghosting and Chrome browser

Recently we started to notice a screen ghosting issue on a Windows 7 Pro 64-bit PC.  The PC has been in use for some time but the issue had started to worsen.  The "ghosting" issue as referred to here relates to an artifact of the prior screen or window remaining visible for some period of time after a screen has been moved or closed.  It might also be described as a "lag" or as a screen display/refresh issue.

Since a Google Chrome browser with the latest updates was normally always loaded and active running in the background on this PC, we didn't have a reason to suspect the browser as the cause, but when closing the browser, we noticed that  the screen ghosting problem stopped.  It also stops we realized when the browser is minimized.

Investigating further, it appeared to be possibly related to a setting in Chrome relating to hardware acceleration.  The specific setting is at (with the browser launched and having focus):

ALT-F (hold down ALT then press F and release - or in the upper right hand corner of the browser window, click on the round button with three dots)


Scroll down and clicked on Advanced

Scroll down to the System section

Slide the Use hardware acceleration when available option to the left to turn it off

Click on Relaunch


Hardware acceleration off

At first it seemed like this resolved the issue on this particular desktop PC.

But no.   We noticed that the "ghosting"  still occurred when the browser window was in the background of another application's window.  Minimize the Chrome browser window behind, and the behavior disappears.

There have been suggestions made elsewhere about also clearing the Chrome cache, and running  ipconfig /flushdns and netsh winsock reset at the command (cmd) line and re-booting.  The Chrome cache is regularly cleared from this PC. Clearing the cache did not change the behavior.   So we then ran the ipconfig and netsh commands (but with low expectations) and re-booted. 

The problem remains and must relate to some other Chrome setting.  

 Knowing that the ghosting problem seems to fully disappear when Chrome is minimized helps help to manage this annoying behavior which we've been unable to duplicate using any other combination of running programs.

Monday, December 31, 2018

2018 year end and upcoming changes

We will be posting information about 2018 year end payroll processing including W-2's, upcoming federal and state changes including the new state of Washington tax for medical/sick leave, 1095 issues and more here shortly.

Friday, November 30, 2018

Colorado and South Dakota sales tax changes likely mean higher costs for all

The Colorado Department of Revenue earlier this month announced changes that would be going into effect December 1, 2018 (but has now provided a grace period through March 31, 2019 for retailers to implement those changes).   South Dakota has implemented new changes as of November 1, 2018 as a result of a recent Supreme Court decision (see more below) relating to sales tax collection by remote sellers.

South Dakota does not have a state income tax, unlike Colorado, and so relies quite heavily on sales tax revenue.   South Dakota, unlike Colorado, has been one of the 24 member streamlined sales tax states.  There are however some 45 states that have state sales taxes.  The current exceptions are Alaska (although some cities/municipalities have their own separate sales tax)Delaware, Montana, New Hampshire, and Oregon.

In the discussion that follows, "in state" is meant to refer to a business that has a physical presence or nexus in that state; "out of state" is meant to indicate a business that conducts business in the state but that does not have a physical presence.

It should be noted that goods shipped regardless of origin to a Colorado or South Dakota reseller remain exempt from sales tax, i.e. nothing has changed in that regard.

Some brief background

In Quill Corp. vs. North Dakota the Supreme Court in 1992 affirmed the longstanding rule that a state could not collect sales taxes from an out of state company that did not have a physical presence in that state.  And that approach has generally continued to be the rule ever since, although some states have made other agreements for sales tax handling  under voluntary agreements.  However just this year in a closely decided Supreme Court case involving this time South Dakota (see links with respect to the Supreme Court decision as reported by various sources at the end of this blog), the position of the court was flipped, and the floodgate has therefore opened for states to attempt to collect sales tax on "retail" sales made by out of state companies without a physical presence (nexus) in their state.

The potential nightmare for businesses

South Dakota had destination based sales tax rules for in-state retailers but Colorado has not.  The recent Supreme Court case emboldened Colorado to implement changes for out of state retailers at the same time as its making changes for in-state retailers.  So Colorado is also now switching to a point of destination concept for sales tax collection like many other states have, and also implementing rules for out of state retailers at the same time. Over 30 states have now changed to destination based sales taxes.

Colorado has historically been known to have notoriously complicated sales tax rules and regulations. The problem for Colorado businesses who either deliver or ship products to a Colorado address however is the sheer number of taxable jurisdictions (almost 700 of them compared to just over 100 for South Dakota).  The tax cannot be calculated based on the county of destination since there are many more tax jurisdictions than counties (even in the much simpler case of South Dakota, it has 40 more taxable districts than their 66 counties).  Zip codes are also largely useless in basing sales tax rates as well.

Sales tax compliance is already heavily burdening business of all sizes and has a significant cost.  Colorado already has one of the more complicated sales tax reporting forms of any state. The new requirement forces businesses to establish sales tax "locations" against which taxable sales and related information will now have to be reported.  

The important exception

Colorado has adopted the same rule as South Dakota for businesses without a physical presence.  Out of state or "remote sellers" that have less than  $100,000 in gross sales in the state AND fewer than 200  transactions, are excused from the requirement.  All others however will now have to follow essentially the same procedure as in-state retailers and procure and pay a small fee for a sales tax license in either state (plus also a small advance deposit in Colorado) and will have to compute sales tax based on the delivery address, charge it to the customer, and account for and remit/report the tax.  

Sellers of lower priced retail goods involving a higher volume of shipments could easily have a problem with the 200 transaction limit in either state.

What about shipping?

Different rules apply to shipping and delivery costs in these two states.  Sales tax applies to freight as a general rule in South Dakota for both in state and out of state businesses.  In Colorado it is a bit trickier.  If the delivery charge is separately itemized, it is exempt from sales tax if the purchaser (i.e. retail customer) could pick up the item at a location within the state (regardless of how inconvenient that might be).   If they can't, then freight/delivery/handling charges are subject to sales tax in Colorado.  This then targets "online shippers" i.e. out of state sellers.

These rules have not changed, but in light of the new rules that impact out of state businesses, they do come into play potentially in a new way.

Good news for local businesses?

Just about everyone is in favor of helping local businesses.  But the devil is in the details and the resulting overall impacts.  

The new changes may help some in-state businesses who compete against out-of-state "retailers" (i.e. companies that ship to retail customers) but the administrative and compliance burdens being placed on some of those same companies with a physical presence within Colorado and South Dakota potentially offsets those benefits. Further Colorado and South Dakota businesses shipping to states outside of Colorado will now have to deal with this same issue in reverse.  For some, the administrative hassle of shipping outside their local area may be a disincentive to do business there, leaving consumers with fewer available resources and less competition.   Some out of state sellers may have products that aren't otherwise readily available locally.

Business are already unpaid tax collectors for federal, state and local governments.  They do their best to meet the myriad requirements constantly being imposed on them and in the process have increased staff and technology costs to try to meet requirements such as those now being imposed by Colorado and South Dakota.  

Good news for consumers?

The pursuit of sales tax revenue from out of state companies leads to the perception that these business aren't paying their fair share. Yet these aren't taxes paid ultimately by business but in fact represent a tax increase on local residents.  It is the local residents of Colorado and South Dakota that are now being levied in essence a tax increase on certain interstate sales   Ingrained buying habits may not lead to any change in the near future in terms of how products are purchased.  The net result is that this is a tax increase and because of requirements being imposed on both in-state and out-state companies, product cost themselves may have to be increased to cover the additional overhead that businesses will incur.

Our preliminary conclusion

We think it may be a mistake to so quickly applaud the recent court decision as some have.  And we do not think that states should immediately start to implement draconian changes at this point with respect to out of state sellers. There could for example be congressional action as a result of the recent Supreme Court case based on the concept similar to taxation without representation, i.e. undue regulation without representation.  

Changes needed to be made, yes.   But was this in the end an efficient, better, streamlined approach?  Probably not.  Will these changes benefit local residents?  No, at least not in the short term.  Will these changes benefit businesses?  It could ultimately benefit some local businesses, however, some of the other changes and complex tax calculations and related reporting requirements will make doing business both for local and out of state "retailers" more costly and that means higher costs for consumers, and it could lead to higher prices even in the distribution/wholesale chain.

We constantly hear about tax simplification and reduction and instead we tend to experience simply the replacement of the old with a new equally convoluted system. 

At the very minimum, if a state imposes complex requirements as is now the case with Colorado, and to a lesser degree South Dakota, that state should provide completely free and simple means for businesses to determine what an applicable sales tax rate should be.  This means that the government agency itself must provide that service, or pay a third party to provide that service and make it available to anyone that does business in that state.   Business should not be forced to not only operate as unpaid tax collectors, meet filing requirements which are in many cases quite onerous, and be subjected to penalties and audits and ALSO be forced into paying for annual or monthly subscriptions to third parties in order to most efficiently and quickly lookup sales tax rates.   Free options with daily or similar limitations are also not acceptable.  

Rather than complicate already complex and in reality quite ugly sales tax collection requirements and systems in what is really a disguised tax increase, states would be better off looking at more uniform and equitable ways to raise revenues from their residents using the simplest possible approaches and in a much more transparent manner.   Sales taxes as currently implemented simply don't work fairly nor efficiently in today's world.

States should not look at themselves as separate countries which seems to be the trend.  We need much more consistent and uniform rules that apply to a country made up of states that should be much more united in their approaches to everything including taxation especially when it involves interstate and related commerce, and the fact that U.S. citizens travel and move quite frequently around the country.

Meanwhile for Advanced Accounting users

In the meantime, what are the options for Advanced Accounting software users?

Nothing changes for your customers that are resellers (unless in the case of Colorado they want non-taxable sales reported based on their six digit location code).  Resellers not normally subject to tax should continue to have their tax flag unchecked in AR-A View Customer Information.  Potential retail customers should continue to be flagged as being subject to tax.  One problematic issue is the tax authority. Ideally the tax authority should match the state's tax jurisdiction and its overall tax.  For businesses that deliver/ship to few locations (which is probably unlikely for most), then create new AR-L-A tax authorities with the appropriate total rate (don't worry about splitting that into districts) and linked to the appropriate vendor code and GL liability.  For customers with potentially many different jurisdictions and rates plus the fact that many customer will not necessarily be repeat customers an/or to efficiently handle new customer orders, a different approach may be needed.   Currently we have in progress several different tools to automatically obtain the sales tax rate based on the delivery address.  This will also have to be linked in a different or alternative way to the appropriate taxable jurisdiction.  It may also be necessary in some cases to allow the user to enter a manual tax rate (normally that is never the case) after the appropriate rate is determined manually on an interim basis.   Users are encouraged to contact us to discuss available options to streamline sales tax handling.

Some South Dakota Supreme Court references:

New York Times:






Colorado Dept of Revenue Sales Tax Basics and links:

South Dakota sales tax references:

Tax guide:

Remote seller bulletin:

Sales tax on shipping/delivery charges


South Dakota:

Wednesday, October 10, 2018

Defer the Win 10 October 2018 update

The October 2018 Microsoft update (version 1809, dubbed Redstone 5) may cause some PC's to crash that do not have sufficient disk space.  Further, the update will likely not be ready for prime time deployment in business environments.

A couple of preliminary articles warning of potential issues:

While ensuring that your devices have plenty of available storage space going forward,  our advice as always for business users:  do not automatically update to the next major update (like the October 2018 update).  The 1809 update should be deferred.  

For Windows 10 Pro users, the simplest way to defer the update is to ensure that your Windows update settings under Advanced options are set to "Semi-Annual Channel" rather than "Semi-Annual Channel (Targeted)" as outlined below.

Windows Update Settings (Windows 10 Pro ver. 1803)

Advanced options under Windows Update Settings (Win 10 Pro ver. 1803)

You may also wish to pause updates for the next 30 days as a temporary stopgap measure (see example above), and more importantly, set the next feature update to 180 or even 365 days (also see example above) to allow time for issues in the October 2018 update to be resolved.

A few additional references with various additional approaches to consider in blocking this and other Windows 10 updates:

Thursday, August 23, 2018

Adv 8 autocomplete and SO notes display

To document just two of the many new features in the upcoming release of Advanced Accounting 8, this first video covers the new "autocomplete" feature when entering a product code in the enter/change sales order option:

There is a new setup option in SY-A-B that allows you to default the "autocomplete" check box either on or off.

A second video covers a new feature with respect to the display of notes attached to sales order line items:

A mentioned in the videos, for now we have added the autocomplete and note display feature in sales order entry only, but that may be expanded in the future to purchase orders and quotes (with respect to both features), and the autocomplete feature may be expanded to other inventory/product code lookups  as well as to other types of lookups. 

(Your browser will need the ability to support videos in MP4 format.  If you have any issues in playing these recordings, please let us know.)

Technical tidbits:

The autocomplete feature simulates to a fairly high degree what end users are experiencing when searching for information on-line.  The term  autosuggest is another way it is sometimes referred to as well as: look ahead, typeahead, search-as you-type, incremental search, instant search and others.

In the TAS Professional/Premier programming world which includes software products like Advanced Accounting,  we've long had this feature in lookup lists or grids where it has been referred to as "Fast Search."   In fact, in graphical versions of the TAS programming language, data grids have even included a property called FastSearchFld to reference a text field that is connected to the grid for the purposes of finding matching characters in that field as they are typed.

How this new autcomplete feature has been implemented, however, is from a single entry field that it not connected to a grid and so in that respect is new, and in fact was not realistically possible until our release of TAS Premier 7i release 11 which included enhancements to the TListBox object.

Users should hopefully understand how to select the desired item to "complete" the rest of the product/item code but it does have to work a little differently than an autocompletion in a web browser search:  the main difference is that you don't press the enter key nor use up/down arrow keys to select the available option in the list box beneath the product code entry field but instead use a pointing device to select/click the desired item: it then auto fills the product code field and moves the user automatically to the product description field (which is in turn then automatically populated with the product code's default description as established in the inventory module).

Adv 8 autocomplete

Advanced Accounting 8 main menu

Tuesday, July 10, 2018

Short dates revisited

Short dates allow a software user to enter the year of a date by just indicating its last two digits.  It is convenient and saves time.

The problem with short dates is that they have to be interpreted as to which century they fall in, since they are after all only denoted with two digits.

This was the infamous Y2K problem when systems interpreting those last two digits after 1999 ("99") rolled over to 1900 ("00") instead of 2000 (also "00").   At some point, however, when whatever sliding century logic is in place and the end of its 100th year is reached, then a "Y2K" problem recurs.

For the most part, calamity does not ensue when the "next century" begins because software typically works on a relative basis.  The only real problem for accounting software for example was that once we were in 2000, the software (depending on the version) might not understand that "99" was older  then "00."  And while this would be a problem for the proper display of certain detailed data when crossing years, it in no way prevented the software from continuing to work within the relative space of the "current" year.  Hence, the world kept turning and life moved on.  The main problems that users had in 2000 who failed to move to a compliant system was when running a report that crossed into a prior year or where there was date logic that required comparision with pre-2000 dates (such as making an accounting entry into a prior period).  After a few years however most of those issues also became moot for those users who decided to live with that problem (although older historical data would still be out of chronological date sequence order).

The Windows operating system deals with the sliding century for short dates through regional settings where date formats can also be assigned. These settings also impact how short dates are interpreted.   XP Pro, Windows 7 and Windows 10 all default the century as 1930 to 2029 (which can be changed via the Control Panel under Clock, Language and Region in Windows 7, 8 and 10; under the Control Panel's Regional and Language section in XP Pro).

It is the application  itself typically that determines the sliding century and not the database. So for example with Btrieve/Pervasive data that we frequently work with, there was no Y2K type problem:  all date values were already being stored in a long date format.   It is instead the application that has to tell the database engine how to interpret the short date which is then saved into a long date (albeit potentially in the wrong century).

In the TAS programming world and the applications written in it (including Advanced Accounting), we wrote a memo in 1998 outlining short date issues in various versions of the products that then existed.   See Year 2000 issues and statement of year 2000 compliancy.    No version prior to 5.1 was technically compliant.   Versions 3.0 (and prior) were not at all compliant.  Version 5.0 was meant to be compliant but had some issues in the year 2000 itself.   

Programmers of highly customized TAS 3.0 systems (including highly customized versions of Advanced Accounting 3.0) typically chose not to move those systems forward into version 5.1 as the year 2000 approached, but instead took on the time consuming task of changing every defined short date field (both temporary variables and permanent field variables established via the data dictionary) from the short size (i.e. 8) to the long date size (i.e. 10).  Technically the data files did not require a restructure because the byte size of the field wasn't being changed, but typically the data was nonetheless restructured and every single use of those fields had to be identified and changed including on every screen and report form which required extensive manual repositioning of each and every date field since they now occupied two additional characters and also because of how the TAS 3.0 screen editor worked.  To migrate the TAS 3.0 code forward was admittedly potentially costly particularly for programmers who had not been working with the newer versions and were not familiar with them (version 3.0 did not even support functions), plus because it was relatively primitive code to start with, so some re-writing of code was inevitable; hence the long date approach was typically always chosen.  Converting code forward from version 4.0 (assuming it was written in that more modern language) is easier than 3.0.   But there was a better way than the above in terms of dealing with the Y2K issue even staying in the 3.0 version.

Version 5.1's sliding century, as outlined in our 1998 memo, was set by the prior publisher to be 1920 to 2019.   That century period however is now coming to a close and anyone running the  5.1 version will have to anticipate making some changes since January 1, 2020 will be here fairly soon, and since a 01/01/20 (mm-dd-yy) date will be saved by the 5.1 runtime engine as 01/01/1920 (mm-dd-yyyy) internally and not as 01/01/2020.    So the exact same issue is coming up for the 5.1 version that users of 3.0 versions were faced with in the 1998-1999 timeframe.  But does this mean that the same long date solution is required?   While that would be a potential solution, no, nor it is necessarily the optimum solution.

Before outlining an alternative solution for version 5.1 (besides migrating the application to a newer version altogether), it should be noted that the sliding century of the current version 7i (then TAS Professional 7 as first released by us) was expanded back in 2004 to be 1961 to 2060.  Users therefore of our 7 and 7i runtime versions should have no worries with respect to short dates.  Prior to that in TAS Professional 6 as released by Business Tools, the sliding century was defined as 1931 to 2030, so even a TAS Pro 6 user has nothing to worry about for now with respect to short dates.

Version 5.1 users do have another option that does not involve having to modify and adjust every single screen and report form nor change all of the temporary and permanent data variables in every program.  Instead, a one-line function can be called right after any field with a date value is being assigned and its century then adjusted programmatically.    As with the long date option, it does still require that programs with date values be recompiled and still requires some amount of work.   But it otherwise should involve far less time, end users will not notice any difference, there will be no repositioning issues, and users will still be able to enter short dates.

An example of the type of alternative function for 5.1 systems using short dates which we have called get_new_date() is outlined below.  We have placed this function in a 5.1 library file (Addsum.lib) in-house for use by systems we support that may need it (the semi-colon reflects the principal way of commenting a 5.1 program):

;Assume that the permanent field BKAR.INV.INVDTE 
;(the AR invoice date) has a value before saving 
;it to its corresponding data file


And here is the function contained in the LIB file (the calling program needs to have a #LIB compiler directive referring to that file and since all of accounting software programs already have a compiler directive referring to the Addsum.lib file where we have placed it, it creates no additional work):

;Copyright 2018 Addsum Business Software, Inc.

define old_date,ret_date type D size 8 local
define newyear_a type A size 4 local
define longdate_a,newdate_a type A size 10 local

func get_new_date old_date

   ;we are simplistically assuming that any date less than 2020

   ;needs to be adjusted - there are many different ways 
   ;this could be accomplished, this is just one example
   ;NOTE that more variables have been used than
   ;absolutely necessary to make it somewhat more understandable
   ;this routine could be used on data saved with older
   ;versions, changing 2020 to a date such as 1980
   ;and then when re-saved back to the data file, a date in 
   ;the wrong century would then be fixed

   if val(year(old_date))  < 2020
      longdate_a = dtoc(old_date)
      newyear_a = "20"+mid(longdate_a,7,2)
      newdate_a = mid(longdate_a,1,6)+newyear_a
      ret_date = ctod(mid(longdate_a,1,6)+str(newyear_a))
   ret ret_date


Just as there were reasons for some users to stay with TAS 3.0 and even though 5.1 is also 16-bit (unlike newer versions), the same reason for staying with a highly customized TAS 5.1 system persists potentially into 2019 and beyond just as it did in 1999 with TAS 3.0.

Related information/posts:

Year 2000 issues and statement of year 2000 compliancy (1998)

From Books 2.04 to Advanced Accounting 7i  (2017)