Home Page link  

Whoops! Microsoft has new accounting product

  
Groups | Search | About
User Password
Register Now! Lost Password?

QuickBooks Discussion board - Discussions about the popular financial software by Intuit

 Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Whoops! Microsoft has new accounting product HeyBub 10-30-2006
Posted by Jesper [MS] on November 3, 2006, 1:03 am
Please log in for more thread options
 Hi "klunk"

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

A small note regarding this:
> 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.

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


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



Posted by klunk on November 3, 2006, 1:14 pm
Please log in for more thread options
 "Jesper [MS]"
> Hi "klunk"
>
> Thx for trying the free Office Accounting 2007 Express we appreciate it.
>
> A small note regarding this:
>> 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.
>
> 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.
>

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.







Similar ThreadsPosted
Product Idea? July 3, 2006, 6:04 pm
Choosing a QB product January 14, 2007, 12:20 pm
Does Quickbooks Pro 2008 Require Product Activation? March 31, 2008, 12:42 am
QuickBooks Enterprise vs. Microsoft GP? April 3, 2007, 5:17 pm
Microsoft Explorer Update Interface November 22, 2006, 11:21 am
Integrating Quickbooks with Microsoft Access January 7, 2007, 1:07 pm
HOT Reqs : Microsoft Business Solutions | 12+ Months | Chicago, IL (Functional and technical) May 14, 2007, 4:41 pm
Looking For Accounting Job? March 16, 2007, 1:53 pm
Looking For Accounting Job? March 20, 2007, 3:45 pm
Looking For Accounting Job? March 23, 2007, 7:20 pm

Contact Us | Privacy Policy
This site is not affiliated with Intuit - makers of Quickbooks and Quicken software
This site is not affiliated with Sage Software - makers of Peachtree accounting software
XML SitemapXML Sitemap