Trouble Enumerating SQL Server Instances 32 Bit And 64 Bit Mode

Hi,

I have a problem enumerating SQL server instances on a 64 bits server W2K3 R2 SP2, running SQL 2000 sp4 (32 bits), SQL 2005 Express sp2 (32 bits) and SQL 2005 Developer sp2 (64 bits).
I am using the same way as the sample (found on SQLDev.net) ListSQLSvr application to enumerate the instances.

In my case i have the following instances defined:

MYPC - SQL 2000 (32 bits) (default) instance
MYPCEXPRESS - SQL 2005 Express (32 bits) instance
MYPCSQL2K5X64 - SQL 2005 Developer (64 bits) instance


When i enumerate the SQL instances for the entire network like this:

ListSQLSvr -X
All instances appear (including the instances from other machines in the network, as expected)

When i enumerate the SQL instances on my local machine like this:
ListSQLSvr -S MYPC -X
Only the 32 bits instances appear..

When compiling the ListSQLSvr application to target 64 bit, the result on the local macine shows only the 64 bits instances !?!?

I am using this enumerating code in my installer to fill a listbox and depending on what kind of SQL instance (32 or 64 bits) is selected by the user, I install the correct extended stored procedure and register accourdingly (note the difference between a 32 extended Proc and a 64 bit extended Proc).
In this case I only need the local SQL instances since i want to install the correct extended proc.

Since the installer (MSI file) is one-for-all (32 and 64 bits OS's) it runs the code from a Custom Action DLL in 32 bits. Resulting in showing only the 32 bits instances.
When I would use the 64 bit installer and make my CA DLL to target 64 bits, I would only see the 64 bits instances.
But i would like to see and use all instances in my 32 bit installer and take the appropriate action to install the correct extended Proc.

I think it has to do with some internals of ODBC (SQLBrowseConnect() most likely); When using a local enumeration it uses Shared Memory and when enumerating the entire network (or any other machine) it uses TCP/IP?
If this is true, is there a way to bypass this someway?
Or if this isn't true, does anyone know any solution to the problem described?


Regards,

Albert van Peppen
Senior System Engineer
Insad Grafisch b.v.