Whoops! Microsoft has new accounting product

"Microsoft released on Monday free business-management software aimed at either the smallest of small businesses or at painfully late adopters. Microsoft Office Accounting Express 2007 is for "starting businesses and home-based businesses that currently use pen and paper or spreadsheets" to run their operations...The software is available for free download at Microsoft's IdeaWins Web site. It resembles the Microsoft Outlook e-mail client and integrates with other Microsoft Office software."

Story and links at:

formatting link

Reply to
HeyBub
Loading thread data ...

Intuit used to say "If you know how to write a check then you already know how to use QuickBooks". Microsoft says "If you know how to send an E-mail in Outlook, then you know how to use Microsoft Office Accounting Express 2007". Both are full of themselves.

Microsoft Office Accounting Express 2007 isn't much better than its processor SBA 2006. I guess that is why they decided to give it away for free. To bad Joe Six-pack will only look at cost when choosing his first accounting package.

formatting link

Reply to
Allan Martin

Microsoft Office Accounting Express 2007 isn't much better than its predecessor SBA 2006. I guess that is why they decided to give it away for free. To bad Joe Six-pack will only look at cost when choosing his first accounting package.

formatting link
>

Reply to
Allan Martin

Since I have a Windows Vista RC2 machine setup for testing, I thought I would install MS OA 2007 express and check it out.

The installation went without a hitch -- didn't even require a reboot. And it even installs SQL Server 2005 Express as well. Installer is 330 MB, with a reported 1 GB of install space needed.

After install I checked the install folder and sure enough Microsoft STILL doesn't adhere to their own software development guidelines. Two ActiveX items are installed and registered in the application folder -- OfficeQ.dll and officeq6.exe -- which means they can conflict with other applications that use these if install versions differ. They should be installed to System32.

Tested importing from QB company files after getting the recommended update. Any attempt to import using the "All Data" option failed with a nasty CoreObjX 3.0 runtime error (tried QB files from versions 2004 - 2006). Not very friendly -- and I would think a 2005 or lower import would use the OfficeQ dll which doesn't need QB installed.

Using the "Master Records Only" import it took ~3 minutes to create a new company from a v2005 data file. Not bad., but that's really not that much info to import. I bet the samed data operation takes longer with v2006 files, but I couldn't get it to work on Vista.

As for the interface, on the surface it seems to be a bit of a QB copycat. UI seems more sluggish -- probably more heavily dotNET than QB.

Reply to
klunk

I don't know about copy-cat UI... Microsoft didn't follow that crazy mega-flowchart thing that Intuit put in QB about a year ago.

----- SG

formatting link

Reply to
SG

Hi "klunk"

Thx for trying the free Office Accounting 2007 Express we appreciate it.

A small note regarding this:

Then you should never install any files to System32 as that will cause exactly the kind of dll-versioning problems you mention here. It would be a violation of both XP and Vista logo requirements to do so. Installing the files to the applications own install folder is the correct way of avoiding versioning problems with muliple versions of the same dll installed by different programs.

Thx Jesper

Reply to
Jesper [MS]

"Jesper [MS]"

That would be correct for standard DLLs -- to install to the applications' folder, which makes them essentially private to that application, as long as a .local file is used.

I might be wrong about officeq6.exe, since a search of the Vista registry didn't show a shared CLSID, just a type library. So it might be designed for private installation.

But ActiveX DLLs are registered with the operating system and calls to use said DLLs are made using COM, not by loading the DLL by filename directly. So if different versions are installed in different locations, the last registered version gets used by ALL applications that call its COM interface (unless one of the methods mentioned later have been implemented to preempt the problem).

Here's the classic example: About a year and half ago, when the current version of OfficeQ was 14.2.0.0 (which could read QB 2005 files), Microsoft Small Business Accounting installed version 13.1.0.0 (which could only read up to version QB 2004 data files) in its own application folders, registered OfficeQ, effectively breaking ALL applications a user had installed that relied on OfficeQ to read QB 2005 data. Worse, the MSI installer for MSSBA would launch and "repair" itself if an attempt was made to re-register the newer version, which would revert back to the old one again. The only solution was to either uninstall MSSBA or copy the newer version DLLs into the MSSBA application folder. What a mess. (To be fair, Peachtree did the same thing at that time, so it wasn't only MS causing problems).

Shared ActiveX DLLs depend on each application that installs them to place them in a single shared location and not overwrite newer versions. System32 has been the standard for this. I just searched MSDN and I don't see anything different, nor could I find a prohibition against it.

I am aware of Side-by-Side Components and DLL/COM Redirection introduced in Win98/2000, and Reg-free COM introduced in XP, but I see no evidence of any in the installation of MS OA 2007 or the earlier MSSBA installs. Although I am not absolutely sure about MSOA, the MSSBA installer registered its private and often older versions of OfficeQ.dll, which is opposed to these schemes and standard practices.

And importantly, the company that develops the OfficeQ.dll had always recommended a shared installation in the windows system folder.

In this instance it's all moot anyway. The version of the OfficeQ.dll installed by MSOA2007 is the last of its line. Due to the database change in QB 2006, the data file can no longer be read directly in that and later versions.

Reply to
klunk

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.