PDA

View Full Version : MSDE Objects ...



BCastleman
10-08-2003, 11:16 AM
There are 2 MSDE objects available in the Redistributables list the "InstallShield MSDE 2000 Object for NT Platforms" and the "MSDE 2000" object.

What's the difference? I used the MSDE 2000 object on an XP machine and it seems to work fine. Is the NT Platform version for NT 4?

Also, is there any way to get the MSDE 2000 object to start the SQL Server service without sending NET START SQL Server to the OS?

And, the SQL Service Manager is distributed, but isn't setup to run automagically. Can this be configured to do so or do I have to resort to registry modifications so that it start on reboot, etc?

Thanks,

Bob

DevinEllingson
10-08-2003, 03:04 PM
The current MSDE 2000 object is V4.00 created by version 9.00.

I'm not sure what 'InstallShield MSDE 2000 Object for NT Platforms' is? What version info does the view show? What does the help page look like?

Devin Ellingson
InstallShield Software Corporation

DevinEllingson
10-08-2003, 03:06 PM
Also,

Currently, we don't have any support for starting the SQL Service automatically, so you you will have to use 'NET START SQL Server'.

Devin Ellingson
InstallShield Software Corporation

BCastleman
10-09-2003, 08:31 AM
Screen shot attached

BCastleman
10-09-2003, 08:32 AM
Screen shot attached

DevinEllingson
10-11-2003, 12:34 AM
BCastleman,

The 'NT Platform version for NT 4' object looks like a merge module, though it has the wrong icon. I'm not sure where this merge module came from, for InstallScript projects I would recommend using the MSDE 2000 object, not the merge module.

Devin Ellingson
InstallShield Software Corporation

Chandima
10-13-2003, 11:37 AM
BCastleman,

The "InstallShield MSDE 2000 Object for NT Platforms" is a Windows Installer based merge module. The word "Object" carries forward from previous versions of InstallShield Developer. We traditionally used the word "Object" to describe a Windows Installer merge module that could be configured using a wizard in the IDE. It is NOT an InstallShield Professional object.

This "Object" will work ONLY with Basic Msi and InstallScript-Msi projects. It will NOT work with InstallScript projects. For more information on this "Object" please see KB articles Q108991 (http://support.installshield.com/kb/view.asp?articleid=q108991) and Q108974 (http://support.installshield.com/kb/view.asp?articleid=q108974).

Due to a Windows Installer limitation, a setup that consumes this Object will work only on NT Platforms (Win NT, 2K and XP). It does not work on Windows 9X machines. If you have any further questions regarding this object please post in this thread.

scoteb
10-15-2003, 12:10 PM
I used the code found in the Q108974 and it seems to install ok, but I have a couple questions.

1. How do I set the SQL executable and data directories at run-time? If I can't do that, how do I retrieve this information?

2. Does the MSDE 2000 SP3 object require a reboot before I can do any database actions such as calling "osql.exe" in the SqlBinn directory?

What I want to do is this:
a) Prompt the user where to install the database.
b) Install the database.
c) Add a custom dll file to the SqlBinn directory.
d) Create a database using "osql" or some other method in the SqlData directory.
e) Install .NET components and services that use this database.

Ideally, I would like to do it all in one swoop without having to reboot until the end.

Chandima
10-15-2003, 12:21 PM
How do I set the SQL executable and data directories at run-time? If I can't do that, how do I retrieve this information?
I'm afraid this is not possible. This never occured to me until another user brought it up after the object was released. This Object was in BETA for about 4 weeks and no-one ever mentioned it. I hope to update this in a future release of this object.


Does the MSDE 2000 SP3 object require a reboot before I can do any database actions such as calling "osql.exe" in the SqlBinn directory?
I'm not too sure about that. I know that MSDE 2000 requires a reboot on some machines, but I'm not sure if that prevents you from using Osql.exe or not. You might find an asnwer to this on the microsoft web site (or maybe a more advanced user over here can answer that).

BCastleman
10-16-2003, 01:29 PM
Originally posted by Chandima
BCastleman,

The "InstallShield MSDE 2000 Object for NT Platforms" is a Windows Installer based merge module. The word "Object" carries forward from previous versions of InstallShield Developer. We traditionally used the word "Object" to describe a Windows Installer merge module that could be configured using a wizard in the IDE. It is NOT an InstallShield Professional object.

SO what about the other object that shows up in the re-distributables, the one that says MSDE 2000. This one allows you to set the directories like scoteb wants.

Chandima
10-17-2003, 04:40 PM
The "MSDE 2000" object that shows in the redistributables view was the standard method (reccomended by microsoft) of installing MSDE with your setup. Microsoft provided a set of (windows installer) merge modules which could be consumed by your setup. However, these merge modules had numerous problems. The biggest being that an instance of MSDE installed via these modules can NOT be patched using any microsoft patches. This became a nightmare when the slammer virus hit and everyone had to upgrade to Sp3. Setup authors (who used these modules) had to create patches to their applications which upgraded MSDE to sp3.

Microsoft then released sp3a. In the sp3a readme file microsoft discourages the use of these merge modules.

"Desktop Engine (MSDE 2000) SP3a provides merge modules to support existing applications that use merge modules. The Setup utilities for new applications should be written to call the MSDE 2000 Setup utility instead of directly consuming the MSDE 2000 merge modules".

The "InstallShield MSDE 2000 Object for NT Platforms" was created to address the statement mentioned above.

BCastleman
10-18-2003, 09:25 AM
Thanks, Chandima.

Then I assume the recommended method is to use the one for NT platforms. Damn. Now I have to redo it. :P

Waynets
06-05-2004, 11:41 PM
Originally posted by Chandima
I'm afraid this is not possible. This never occured to me until another user brought it up after the object was released. This Object was in BETA for about 4 weeks and no-one ever mentioned it. I hope to update this in a future release of this object.

(The above was in reference to a question about setting the executable and database directories at runtime.)

So does this mean it's not possible to set the SA password at runtime either? I've got a UI dialog that prompts the user to enter a new SA password for installing MSDE, which I was hoping to pass as a parameter.

If not, I need to figure out an alternative way to install MSDE. There's quite a bit of discussion about it in the forum archives and it's confusing to figure out what the right way to do it is. Here's what I know so far:

1. The well-known "another installer is already running" issue, which I discovered myself the hard way.
2. I tried creating a setup component that would install the MSDE setup bits on the user's machine, and then I create a custom action that calls it from [INSTALLDIR]\MSDE, and I inserted it after the SetupProgress dialog, but the custom action gets called BEFORE the setup bits get installed, so it can't find MSDE's Setup.exe.
3. One of the reasons I figured I had to install the MSDE setup onto the user's machine is because I've got my entire setup compressed into a single exe. Is there still a way to use Support Files to install MSDE this way, and if so, how do I use it, and if not, what's the best alternative?

--Wayne