Invalid Object Error Using SQL-DMO Transfer2 object in WIndows XP Pro

Just a guess... does your development environment include the .Net Framework, and your non-development system not have that?

Thanks for your response jdlambert1.  The development environment has the .Net framwork 1.1 installed.  The 2K Pro non-development environment where the app does work, does not have the framwork installed.  The Windows XP partition has the framwork installed and is fully updated with the exception of the latest media player 9 SP.  My take on this is that the framwork is not a factor.

Sounds like the components didn't register right on the XP machine.  Have you checked to make sure all the SQLDMO dlls registered properly?  XP's system file protection is better than 2000 and some DLLs will not replace.

This article talks about using the VB deployment wizard (crap), but the same applies, check your file locations and make sure everything is transferred and registered:

http://support.microsoft.com/default.aspx?scid=kb;en-us;258157

Brett

Thanks for your response, Arbert.  I'm using InstallShield Developer 7's MSDE 2000 merge module to gather the necessary files for the install.  There is no way to change things in those merge modules that I am aware of.  I do know that only SQLDMO.DLL is registerable in the list you referenced above, however.  After the installation has completed, I have gone to it and unregistered and registered it and tried again with exactly the same problem.  I've been fighting this for three days now.  It's really boring me to death.   I do believe it is something along this line but this doesn't make sense if you think about it.  Since when does an administrator not have full access?  It can't be something missing because I would have had a problem in the 2k Pro install in that case.  I would give up if that was an option, but it isn't.

I recompilled that above procedure to use Transfer object instead of Transfer2 object (omitting the Functions) to see if it was the object itself.  It is not, it is something in the object.   The error is always the same:

[SQL-DMO]Invalid parameter type; must be string or numeric ordinal, or an object; check documentation for this property or method.

It always occurs on the transfer method.  This same code and installation works anywhere except XP.

Thanks again for your response, arbert.   What you're saying is not indicative of a lot of installshield experience using merge modules because you don't get the option to set anything with those.  You take them or leave them.  However, what you said did give me an idea that worked.  I unregistered SQLDMO.DLL and then went through the installed .rll's in the resource folder (PGF\MSS\80\tools\binn\resource) of the XP target machine and manually replaced them from the development partition.  Then I replaced all the SQLDMO related DLL's in the BINN directory.  Once I registered SQLDMO.DLL and restarted the Sql Server service, I tried the program again.  It worked perfectly.  As it turns out, the older files from my development machine (all dated 8/6/2000) worked but the newer files from the merge module dated 4/17/2001 did not work.  By the way, there was no existing Microsoft Sql Server (MSS) folder on the target machine so overwriting dlls was not an issue.  In the 28 years I have in the Micro computer industry, I think I have seen this situation maybe only one other time a really long time ago.  So, because you gave me the idea, you get the points and it looks like you really need them too.  :-)

28 years and you have experienced DLL/RLL hell?????

Sorry, I am familar with installshield and I know you can set the parms for how DLL overwrite happens--you're right though, that may not apply to merge modules...

It's really difficult to say all you mean in writing like this.  The matter of setting parms for DLLs in InstallShield is as you stated above in my experience, but my statement was regarding merge modules only which you also stated may be correct.  I really dislike having to deal with Installshield because I cannot devote sufficient time to it to learn all the intricacies as is necessary to be effective with such a package.  However, necessity is the mother of all invention.  Anyway, I’m going to pin down the specific .rll/.dll combination I need to resolve this current issue and then I’ll let you know what that combo was if you’re interested.  I feel it is pertinent to others because it is the latest MSDE 2000 Merge Module from InstallShield/Microsoft and the same thing is bound to happen sooner or later to someone else who didn’t read this thread.  :-)

You have to admit (I guess), it is easier than it use to be....The last installshield we deployed was a bunch of  C coding (or whatever the Installshield scripting most closely resembles) to handle the running of the msde install through a shell :)

Please do followup on your findings :)

In conclussion, I took the following way:
When using MSDE 2000 with InstallShield Developer 7 (sp4) there is a wizard that comes up when you select the MDSE 2000 merge module object.  It is quite simple and straight forward; unremarkable in itself except to say on the last page you should check the option for Sql Security if you intend to gain access to your server once it is installed.  Once this process finishes, there will be a good number of MSDE merge modules that have been checked for you depending on the options you previously selected.  Two of these options have "DMO" in them.  I unchecked both of these since the enclosed version of DMO does not properly support the transfer method.  Then I encluded two files from my development machine;  SQLDMO.DLL with a target of <ProgramFiles>\Microsoft Sql Server\80\tools\binn and SQLDMO.RLL with a target of <ProgramFiles>\Microsoft Sql Server\80\tools\binn\Resources\1033.  After the IS Project was built, distributed and place on a CD, the installation worked perfectly in the XP OS.  

This is a bit concering to me however.  I don't know the  internal structure of SQLDMO.DLL but out of all the files that are involved with it, only this one is registerable.  The .RLL files must be in a sub-folder specifically named Resource\1033 (if we're talking english) and the others are in the Binn and System32 folders.  Well, this configuration splits build versions.  That makes this approach very flimsy.  I wish there was a real solution to this problem.  But trying to move the hand of either Microsoft or InstallShield is not a small task.

Consequently, although this worked for this problem in this case, I do not recommend taking such an approach for solving problems.  Just because it worked does not mean it will consistently work under all uses employed by SQL-DMO.  

By the way, I tried replacing the entire set of SQL-DMO files and only keep what was needed for MDSE from the merge module.  InstallShield did not understand what I wanted.  :-)

Another option, and probably the right approach to this problem, is to drop the merge module entirely, add a redistributable copy of MSDE 2000 to the installation and use the SQL-DMO installed with it.  All you need to do after that is to figure out how to get a Basic MSI project to execute an MSDE Installation as part of the overall install process.

"Another option, and probably the right approach to this problem, is to drop the merge module entirely, add a redistributable copy of MSDE 2000 to the installation and use the SQL-DMO installed with it.  All you need to do after that is to figure out how to get a Basic MSI project to execute an MSDE Installation as part of the overall install process."

And that's what we have been doing....shell out and run the silent install of MSDE...Not glamorous, but it works :)

Can you say "bandade"?  :-)  Do you suppose InstallShield reads these threads?  Take care, arbert.  I'm going to shell out and run silent now.  :-)