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

GET_RUN_PROG()

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.  

More information and download updates page

New installation download

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:

https://support.microsoft.com/en-nz/help/4284848/windows-10-update-kb4284848

entitled:

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

Background:

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:

https://www.computerworld.com/article/3232632/microsoft-windows/how-to-block-windows-10-april-2018-update-from-installing.html

https://pureinfotech.com/avoid-problems-installing-windows-10-april-2018-update-1803/

https://www.techrepublic.com/article/how-to-resolve-network-problems-caused-by-the-windows-10-april-2018-update/

https://www.windowscentral.com/windows-10-april-2018-update-biggest-user-problems-and-complaints

https://blog.mertech.com/windows-10-version-1803-breaks-some-shared-folder-applications

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. 

Comments/recommendations:

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.