InstallAware

My sql express sp2 plugin is failing after extraction to the local system and running for a couple of minutes. I took the exact command line used to install sqlexpr.exe in the plugin (that is:

sqlexpr.exe SECURITYMODE=SQL INSTANCENAME=SQLASIMV SAPWD="mypasswordhere" ADDLOCAL=SQL_Engine SCCCHECKLEVEL=IncompatibleComponents:1;MDAC25Version:0 ERRORREPORTING=1 SQLAUTOSTART=1 DISABLENETWORKPROTOCOLS=1 reboot=ReallySuppress ) - ran it manually on the command line and it does work (password left out). What might be going wrong with the plugin?
I have no error code. No log files in the sql directory - it never got that far.
Is there another approach other than using the plug-in? Could I just unzip the sqlexpr.exe binary myself and call it with the right parameters? Do I need to use a filebag? I know I might be missing out on the ultimate in compression, but working is worth more to me.

So far I've tried this on XP Pro sp2, XP home - same results.

Why not try with custom logging parameters on the command line?

I did not get any clues from the log.
Is there a way to package up sqlexpr.exe myself, put it in wmb, download, extract and run it? This has to happen before the main install takes place. Will Install Files command work there at all?

Do I need to call an external setup here?

I seems that something inside checksql2005.mia and setupsql2005.mia is signaling that the runtime sql express 2005 sp2 is to be checked and the system automatically tries to use the plugin. Can I use the logic in checksql2005 and setupsql2005 mia, but not pull in the plugin itself?

Sure. Just edit the scripts any way you like! Define a File Bag for your setup files and then call Run Program normally from the bag location. Look at .NET installer scripts for examples of how to do this - the newer versions do not use custom plug-ins but built-in commands like File Bag and Run Program. You can even look at the 64 bit version runtime installer for SQL Express to see how that one works - that one again lacks a custom plug-in.

Thanks, I'll try that. Can you recommend a sample project with a file bag in it? I can't seem to locate one. I'm on version 8.

Samples: User Feedback, Online User Authentication, Multiple Instances, Serial Validation, MS SQL Server Connection, DIFx Driver Installation, Multi-Lingual Setups, IIS Web Sites and Folders.

Again, this installation must take place at the time runtimes are normally installed.

I see - you said .Net scripts.

I cannot find a runtime for the 64-bit installer of sql express.
Do you have the pertinent 2 or 3 lines that put it on the disk and install it?
I'm trying:
Set Variable SQLEXPR_FILEBAG to
Set Variable SQLEXPR_EXTRACT to
Define File Bag : \\Builds\\IDD\\Navippro\\Solution files\\ASI-MVConnect.Solution\\ASI-MVConnect\\SQL Server 2005 Express sp2\\SQLEXPR.exe, get runtime location of files into variable SQLEXPR_FILEBAG
Run Program $SQLEXPR_FILEBAG$\\SQLEXPR.exe /qb ...

Your script fragment looks good, except need to use full path instead of relative paths!

InstallAware 9 includes the new 64 bit runtimes.

\\Builds\\IDD\\Navippro etc. is the path from the root of the drive where the codebase is when we run the build in automated mode on a build machine.

Most developer machines are setup on the C: drive, the build machine has all the code on the D: or even E: drive.

This does work and seems to be a way around the lack of relative paths in IA. I suppose we could work out a subst drive method, but it seems too complex.

Hi!

We use SVN as a code control system, so we've encountered the same issue with Relative Path.
I was able to find a solution for this. I'm using a Compiler Variables, like this:

#DEPOTDIR#\\SubFolder1\\SubFolder2\\File.dat
where #DEPOTDIR# - is a compiler variable with the value like: E:\\FileDepot, or something. Pretty easy, but of course pity that IA does not support relative paths like in MS DOS commands.

btw, as you already know compiler vars can be used in automated builds. So for miabuild.exe ypu can use one path, and for the local development another.