11 Comments to “SBT Flashback”

  1. Doug Hennig

    Mar 5th, 2014

    Actually, SBT (renamed to Sage Pro after it was purchased by Accpac International which was later acquired by Sage) was rewritten in VFP and was only recently (this year) discontinued by Sage. There are still lots of Sage Pro customers and resellers, most of whom are being transitioned to other Sage products,

  2. Craig Munson

    Feb 15th, 2016

    Wow. found your article regarding SBT running from 1990. We have been using the old DOS based SBT accounting modules since 1991. All our forms and accounting databases are on it and it still works flawlessly except customer statement aging of invoices which stopped working correctly after midnight 12/31/1999 (SBT never realized there would be a year 200o I guess.

    Anyway we have to run it either on an XP machine or a XP virtual machine within Window 7. Our tech guy keeps telling us to trash SBT and go to a windows based accounting program as certain doom lurks for dos based programs in the future.

    My question..Is there a windows based accounting software that will recognize and easily import all my SBT database files? OR is there a Windows version of Sage software or SBT that will do this

    Thanks

    Craig

  3. Eric Selje

    Feb 17th, 2016

    Craig, here’s are some suggestions from the MadFox User Group:

    – There is an upgrade path to ACCPAC Pro Series, built on VFP. It even supports SQL/Native DB

    – Found this just searching for SBT Accounting. This is a consulting firm offering a known conversion path. I do not vouch for them.

    Notice to Businesses Currently Operating VisionPoint Software

    As you may already know, Sage Software no longer supports the ACCPAC (SBT) VisionPoint product. The decision to no longer support the SBT VisionPoint software was unfortunately made by Sage in 2007. If you are currently using VisionPoint, and would like to know about your options regarding migrating to a different financial accounting software system, please call (727) 421-7314 to speak with Eleanor Mullaney.

    – I believe SBT also had a windows version. It is written in VFP. Should be fixable. Suby, Von Haden & Associates used to use it and support it.

  4. Michelle Liu

    Mar 11th, 2016

    @Craig: The company I work for is still using SBT as well, but we’re able to directly access the DBF files and get them into CSV/SQL format if we need to do external manipulation (e.g. update web MySQL database with updated inventory etc). I run an automated script that gets the latest CSV version of the database files of interest and update our MySQL database with that information, so that our accounting software and our web database can be in sync.

    DBFmanager does a pretty good job of viewing/editing the DBF files directly (http://dbfviewer.com/), but there is also a free Python DBFreader module (http://dbfread.readthedocs.org/en/latest/) allows you to easily convert the DBF database files that SBT uses into CSV or SQL, which can then be inserted into other SQL databases, or MySQL etc. So it should be pretty easy to transfer the existing database files over to another system.

  5. Chris Richardson

    Jun 21st, 2016

    There’s a company I do contract work for and they still run SBT pro back in 2012 or 2011 they had it running on a dying Novell system and another person told them that they wouldn’t be able to upgrade the server side.

    I’m quite young but I’m not new to IT and I’ve been involved in a bit of everything from development to system administration to information security.

    So taking a look at it I quickly realized that all the system hosting it was is a simple file sharing host, I quickly migrated it off this system that had dying drives and was running outdated Novell software just waiting to be compromised or die in some way simply put it was certainly holding them back.

    I had migrated things up to windows 2008 server, and they worked fine everyone was happy.

    Now I’m being told another person (the same person that told them this was not possible) is telling them that they won’t be able to run the software on newer clients above XP and as we all know XP has hit it’s EOL date so it’s best to not be running it at all especially with the ransomware floating around.

    Any who, I haven’t quite looked into the issue but from my research it seems people on Windows 7 64bit or any other 64bit seem to experience database corruption issues but it’s a hit or miss.

    The only suggestions I would have for that natively is to run it in a ‘compatibility mode’ which I haven’t seen anyone mention yet, the next suggestion is to run the DOS version of SBT in DosBox which I’ve tested and it works perfectly… though I haven’t tested it so thoroughly I could tell you whether or not it causes database corruption but I can easily assume things will operate quite smoothly.

    https://www.dosbox.com/

    Maybe one of these days I’ll throw up a tutorial on it.

  6. Michelle Liu

    Jun 27th, 2016

    @Chris: We were told the same thing (that we couldn’t upgrade our server, or run it on other clients), but I was able to successfully move SBT to a new, powerful Linux server running a Samba fileshare (since the database is file-based). We’ve also been able to use SBT with no problems whatsoever on all Windows clients (Vista, 7, 8, and 10), so I’m not too sure what the original IT tech was saying. No installation of anything on the clients is required either: just click on the Vpw.exe file and it’ll run. (It even kinda worked on a Linux box running Wine). Only thing is, though, since it’s possible to programmatically access and read the DBF files, it’s a bit of a security risk for those files to be there available to anyone who needs to use the program (yet they need read/write access in order to use SBT). There was still this issue before when we were on Windows Server as well; was anyone able to get around this?

  7. Chris Richardson

    Jun 27th, 2016

    Michelle Liu,
    The simple solution is to do ACL based access I’m not sure if samba on Linux would allow for this but I’m pretty sure you could setup specific users that are allowed to access read or write files instead of allow completely anonymous access.

    My personal solution was to setup a Active Directory Domain Controller then link the windows server where I had the file share and individually grant each employee different access to the SBT share.

    From there I created a logon script on the Active Directory controller to automatically map the SBT drive on their computer, all they had to do was login to the domain on their computer.

    That seemed to be enough to setup some basic ‘security’ around any ‘guest’ being able to access and read the DBF files.

    Though I believe there was various registry hacks that took place in that implementation in order to prevent file locking from multiple users accessing files at the same time, since Visual Fox pro has it’s own built-in file blocking for the write access it would still operate just fine.

    Another solution you can look into is
    Terminal Services RemoteApp ( https://technet.microsoft.com/en-us/library/cc753844%28v=ws.10%29.aspx )

    (http://www.fmsinc.com/microsoftaccess/terminal-services/remoteapp.htm)

    If you did that I’m quite sure it restricts access to the file system and the user is only able to stream the application’s binary which is running on the remote host preventing them from even being able to locally attack it to bypass password authentication or etc as the application is not running on their machine.

    I always thought of how much the old OnLive service protected video games in terms of cheating in any form, it’s really sad to see it didn’t succeed.

    But my point is that if the application is streamed and file-access is not provided to the system it should be sufficient to protect against most sophisticated attacks I personally have not audited Visual Fox Pro or SBT to check for any other potential vulnerabilities like some kind of Command Injection or Overflow issue… but it should be sufficient.

    Also, the added benefit is if anyone did experience issues with newer OS or just randomly with a single machine while running it the TS RemoteAPP would be simply running on the single server rather then each individual client meaning instead of fixing 20 systems compatibility settings and risking DB corruption or problems constantly you fix the one and all the other systems inherit it when launching it.

    Also I’ve researched it quite a bit being a Sr. Sys Admin with a development and security background has it’s advantages when it comes to dealing with old technologies and thinking of workarounds in order to continue to maintain the technology while keeping it off the network or segregating it to a low-risk point of the network, so yeah I’ve done the WINE attempts though no one in the company used a linux desktop and I’ve also pushed it even onto a tablet/phone via the DOS binary and dosbox and experienced no issues at all.

  8. Mike Ryan

    Jul 8th, 2016

    We run SBT 3.0 (Fox for Windows) and have been for over 15 years. We run Windows Server 2012 and all the SBT users run on Windows 7 32-bit clients. The funny thing is they all require a disk in the CD/DVD drive to function completely! We have it interfaced to UPS Worldship and have built other manufacturing and distribution programs using VFP 9 that still talk to SBT files in real time. No plans to switch anytime soon. It’s far from perfect, just like everything else.

  9. Michelle Liu

    Jul 8th, 2016

    How did you go about implementing the real time SBT interface? We’re trying to do something similar, but ours isn’t exactly real time since we’re just polling and checking the DBF files for changes. We’re thinking of trying out using directory/file watching and triggers instead, but I have a feeling that we’d get a lot of false positives/triggers from that, though I’m not certain.

  10. Michelle Liu

    Jul 10th, 2016

    That’s really interesting….thanks, going to check that out! 🙂

    Yes, I think that would be the most secure method, since filesystem access would be restricted to only the server user running the program. I’ve set up individual samba users and granted only certain users access to the SBT share, but unfortunately, the way SBT seems to be set up is that the user that runs the program must also have read/write access to all the files SBT needs to run (e.g. the DBF files). Hiding the DBF files in the samba config resulted in a non-functional SBT due to insufficient permissions, so at the end we ended up just leaving it as it was…but it is also extremely insecure since the user has read/write access to all the SBT files, which means that as long as they have the technical know-how to read the DBF files (e.g. the Python dbfread library, or a program like DBF manager: http://dbfmanager.com/ ) they can access all the data in the database without restriction, regardless of the permissions set for their SBT account.

    So, yes, I think that the remote application streaming might be a good option to make it a bit more secure. I’ll definitely look into it, thanks!

  11. Jim Gibson

    Jul 18th, 2016

    You can use also DBF Viewer 2000, allows view, edit all DBF formats and convert it.

    http://www.dbf2002.com


Leave a Reply


Time limit is exhausted. Please reload CAPTCHA.