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:

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 (with 10/14/2019 postscript)

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 every lookup list with a date field) 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 - see however the postscript below):

;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.

Postscript:  (Oct. 14, 2019):

As we prepare to actually implement the above approach on over a dozen systems, many that are highly customized, the example above was merely an illustration of how the problem might be solved.   That prior example however was simplistic because  while it would properly place a date entered between 2000 and 2019 into a range beyond 2020, users might actually need to be entering dates in those ranges and it also would put any date entered prior to 2000 in the 2020-2099 range.   The fact that some dates might need to be tested that contain no date value (i.e. 00/00/00) needs to be handled as well.   A revised version implementing the same sliding century as implemented by us in newer graphical versions of TAS is:

;Copyright 2019 Addsum Business Software, Inc.
:get_new_date - ADDSUM.LIB

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


   ;no date passed, return
   if old_date=0 then ret ret_date

   if val(year(old_date))  < 1961
      longdate_a = dtoc(old_date)
      newyear_a = "20"+mid(longdate_a,7,2)
      ;exceeds the sliding century so just return the date passed
      if val(newyear_a) > 2060
         ret old_date 

      newdate_a = mid(longdate_a,1,6)+newyear_a
      ret_date = ctod(mid(longdate_a,1,6)+str(newyear_a))
      ;date is OK as is, just return what was passed

   ret ret_date


Note also that the get_new_date() function has to be called in connection with any permanent field dates that are saved to a data file as well as in logic involving dates or with dates used as variables in ranges for reports. In TAS 5.1 (and prior) and in TAS Premier legacy RUN programs (where no short date adjustment is required), date fields are entered by the user via ENTER programming commands.  The get_new_date()function should typically be called in a post (or vld) in association with ENTER.  In programs where a date is entered but its value is not needed for any logic until a SAVE to the a data file occurs, then it could be potentially called right before the save instead with simply a single line of code required.  The number of code changes per program typically will be few but each program that involves the use of a date field has to be separately evaluated to determine the best and simplest approach (just as it would if dates were converted to long dates which would then be more invasive in terms of other changes that would be required). 

Example 1:

   define somedate type D size 8
   ;mount a screen that includes the field somedate
   enter somedate post chk_somedate()
      ;unique per each field entry
      func chk_somedate
         somedate = get_new_date(somedate)
         ret .t.

Another approach would be to use a pointer field and set it to the enter field in a pre:

Example 2:

   define somedate type D size 8
   define date_ptr type F
   ;mount a screen that includes the field somedate
   enter somedate pre set_someptr() post chk_somedate()
      ;unique per each field entry
      func set_someptr
         date_ptr -> somedate
         ret .t.

      ;this would be placed into a LIB file and used generically when possible
      func chk_somedate
         &date_ptr = get_new_date(&date_ptr)
         ret .t.


Unfortunately using a pointer doesn't reduce the amount of code needed and requires both a unique pre expression and a generic post expression versus a single unique post expression per field.  Since the goal would be to use the least amount of code as possible, example 1 has a slight advantage over example 2.    So most date fields that are entered will need a new post (if one doesn't already exist; could also be placed in a vld expression) and a three line function. 

We have now (as of October 14, 2019) also changed Advanced Accounting 5.1's maintain database program so that it too will make adjustments to date fields (any type "D" dictionary field that is size 8) for the sliding century specified in get_new_date() which physically resides in ADDSUM.LIB for Advanced Accounting but could be placed in any library file that is commonly included (with a #lib compiler directive towards the top of every program) in a given set of programs.  Otherwise, making any database edits involving date fields could potentially also be saved to the wrong century.

Related information/posts:

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

From Books 2.04 to Advanced Accounting 7i  (2017)

Friday, June 29, 2018

TAS Premier 7i release 13 available

Release 13, our 2018 release in the TAS Premier 7i series, is now available.

The first release of TAS Premier 7i was in 2005.  Since then we have usually released an annual update related to cumulative improvements since the prior release.  This release then marks now some thirteen years in updates in the 7i series.  TAS Premier 7i was in turn based on our 2004 release of TAS Professional 7, building on prior versions released by Business Tools, Inc. including TAS Professional 6.

Releases 11, 12 and 13 taken together could have justified a new version altogether, i.e. a TAS Premier "8," but we have so far decided to simply continue to number these updates sequentially within the 7i series.

The next major release of Advanced Accounting will be based on this release.   Several of our users requiring some of the new features included in rel. 13 have already been using the underlying runtime engine for many months. Enhancements and other fixes and updates have been actively made since release 12, i.e. since mid-November 2017 to the present.

Release 12 made some major changes the full impact of which could not all be fully contemplated until it was more widely tested and deployed at end user sites.   Release 13 resolves the several remaining issues that we became aware of, and provides additional features to deal with the "topmost" behavior which we had to migrate towards in order to solve other problems and to keep up with operating system changes in rel. 12.

One of the issues that surfaced in rel. 12 that rel. 13 resolves relates to the folder lookup when printing to a file that would fall behind the printer dialog box.  Resolving that required a new API call and subsequent extended open file dialog support.  This led us to also incorporate separate but similar calls incorporated within GET_FILES() and GET_RUN_PRG()  so that they could work without having to adjust the Z-order of the calling form in advance (which could be problematic if multiple prior topmost forms were loaded).  These now also have extended file open dialog support. 
Print to file "save file as" dialog invoked by clicking on the folder/file lookup button

GET_FILE() with 5th param set to true allowing it to be used as a "Save as" dialog


A new feature when printing a report and selecting print to file is that the file type last chosen in a runtime session is "remembered" and used as the default in the next request. This feature was responsive to a request by an accounting software user who would at month's end need to send multiple reports to an outside account via PDF and avoids having to scroll the file type drop down box with each and every print to file request.

Another new feature is a function which returns ISO format 8601 date-time values, as well as a function that allows the programmer to retrieve the total number of currently open files in a runtime instance.   Clarification of the number of files that can be opened in a runtime has been made, and the number of files expanded from 255 to 999.

Another new function calls external executables in a Windows "CreateProcess" thread and has the ability to wait before relinquishing control to the calling program, and it also attempt to make the executable that is called topmost.   It is sort of a cross between the existing EXEC command and the TShellExe object.

A significant amount of attention has been also given in this release to help file support.  The WHELP command (as well as F1 form key presses) now attempts to load CHM (Microsoft's proprietary compiled HTML format) files topmost.  Because of the increasing uselessness of the CHM format, we have brought back HLP support for newer operating systems.  The HLP format is actually in many ways more feature-rich than CHM and does not suffer from the blocking problems that have evolved with that format even though it is still the Microsoft standard.  

Wednesday, June 27, 2018

Microsoft fixes beleaguered Win 10 1803 update

Yesterday (on June 26, 2018), Microsoft released a promised update to fix problems introduced by the now infamous Windows 10 1803 update:


June 26, 2018—KB4284848 (OS Build 17134.137) Applies to: Windows 10, version 1803

All of the items refer to 'addressing an issue' including this item:

Addresses an issue where some users may receive an error when accessing files or running programs from a shared folder using the SMBv1 protocol. The error is "An invalid argument was supplied."

The SMB* issue created by the 1803 update was not returning the error quoted that the end user  could actually see to our knowledge.   And it seems to have impacted much more than the fix would allude to. 

*SMB stands for "server message block" and is a protocol used by Windows systems to share information over the same internal network.  As newer operating systems have evolved, different SMB protocols have as well.   Newer operating systems have to be able to switch to a lower level SMB version to communicate with older systems.  Major SMB versions are sometimes referred to as v1, v2 and v3:   SMBv1 (Windows 2000, XP Pro, Server 2003), SMBv2 (Vista, Windows 7 and  Server 2008 ), and SMBv3 (Windows 8, Server 2012, Windows 10, Server 2016).   SMBv1 referred to also sometimes as SMB1 is said to be the least secure, but that may or may not be much of an issue on every business network.

More information


The Win 10 1803 update, known also as the Windows 10 April 2018 update (which started to be rolled out to end users by the first week of May), was actually an entirely new release of Windows 10 involving mostly new features (but with few security features of critical importance; therefore there was no need to rush to install it).   Computer users generally started to begin reporting problems almost immediately following this update; other users who are just barely now starting to install this update have also reported problems immediately following installation of the update.

Some initial reaction and reports about this update:

Our first report of an issue with our users was during the third week of May.  This user had a Windows 10 client connected to an XP Pro PC which was hosting the software.  The user received various Pervasive (Btrieve) status codes including 94 and 3103 on the Win 10 client following its 1803 update. The Pervasive version in use was 9.71 (running a client-server version with the server version running on XP Pro, not officially supported, but it works just as client-server also works using Windows 7 Pro as the server rather than a "true' server).   Yes, a very old version involving an operating system without ongoing updates (which means it is going to work the same every day), but it was working without any problems until update 1803; PSQL version 9.x can in fact be configured to run on every operating system released by MS so far, as can Btrieve 6.15). 
Uninstalling update 1803,  the user's system started to work again as expected.

At first the indication was that the SMB issue would only impact users running older operating systems (the version of the database in use was not the issue) and only when running over a network (which is how most businesses function!).

The most prudent action for the few users that initially started to experience this problem was to rollback the 1803 update, something that many software companies and consultants recommended.  (One source indicated that it would be costly to rollback this patch:  not true.)

Fairly quickly Microsoft acknowledged the SMB issue and indicated it would come out with an update to resolve.

Just this week however an end user of ours suddenly had three Win 10 clients over the course of several days receive Pervasive (in this case PSQL version 12) status code 3012 after the 1803 update was installed yet these PC's were connected to Server 2008 which normally natively supports SMB2 protocol.  So on balance, this was a modern system.   On two PC's, the update was rolled back which resolved the problem.  On a third PC however more than ten days had past since the 1803 had installed itself.  Following a major build, while Windows retains the files needed to uninstall the new build initially, after just ten days Windows automatically deletes those files and you cannot rollback to a prior version without reinstalling the operating system!  This user however was able to solve the problem without having to replace the computer or reinstall the operating system by installing the June 26, 2018 patch referred to at the beginning of this blog post. 


As we have stated again and again, automatic updates are dangerous.

As with changing to any new version of Windows, users should especially wait and postpone major updates; some experts were suggesting to wait until at least August of this year to deploy the Win 10 1803. 

Unless you want to be a guinea pig.

Running programs "across networks" is exactly how programs were designed to run.  That is how executables are normally run with respect to multi-user applications in on-premises, multi-user environments.

It is simple to uninstall and "HIDE" and postpone a Win 10 update using MS provided tools (it if is done quickly).

Users do NOT have to accept every update that is thrown at them nor should they be forced to do so.

Ten days is a ridiculously short period of time to disallow a rollback.  In the example cited above, the end user had been out of town. That user should therefore be penalized?

Policies of forced software updates and ten day time frames where files are automatically deleted are tactics that business and individual users should rebel against in the strongest possible way.

Further and unfortunately, any user that put themselves into a position of automatically installing every single update that comes out more or less immediately is putting themselves into a level of higher support costs and should expect that things may not work the same from one week to the next, and that they **will** have business interruptions as a result. While most security and related computer technology sources stress "keeping your system up to date" to prevent malware and similar attacks, in fact, it is not prudent to put your PC system on the line at the whim of every update that comes out more or less the second it becomes available.  That is not prudent nor wise.  In most cases except for the highest priority security updates, prudence dictates waiting not just weeks but also often months before installing the "latest" updates.  And it is best do be present and monitor those updates while they are being installed to ensure they completely finish successfully.

No doubt the time is coming when our "smart" cars and "smart" houses fail to function the next day following an automatic update.  And then maybe users will revolt against this constant push of untested updates creating constant business interruption and chaos in their lives, as that is exactly what these "updates" often amount to.   

And this is why many savvy users don't put their accounting systems "on-line" at all and accordingly their support costs are vastly less and experience reduced levels of frustration.  And these are points that many in the industry seem to fail to understand. 

It is also noteworthy that users happily running Windows 7 in any configuration weren't impacted by this update.