Hrm... well then, it looks like when the install ran, it did not deploy the *.pkg file, so when the installer action tried to deploy the data, it failed because it couldn't find the file...

No, everything is clean, stock, and default. I didn't tweak anything.

Did you try to install SF to a non-default location (not C:\Program Files\MicroFour\StrataFrame, or whatever the default is...)?  It could be that the install could not locate the *.pkg file for the data deployment, not that the *.mdf file could not be created. 

I'm leaning toward the *.pkg file being unavailable because the log files would contain a few lines and the exception saying that the *.mdf file could not be located; but since the log file was empty, I don't think the *.pkg file was found because it never even started...

No, this is a clean install of SQL Server 2005.



Since the previous message I uninstalled and reinstalled. Got the same error.

Then I ran the install again but chose modify. This time it seems to be generating database activity.



The log files that I have are all named xxx_results.log. The first 3 log files from the 3 installs are all 0 length. Then I have 2 from the Modify that are named Strataframe_results.log and StrataframeSample_results.log.



The Modify has now completed and everything seems to be working. I'm not sure that sending you the logs will help because every log from a failed install is empty and the logs from the modify contain all the expected messages about the databases being created. They are attached nevertheless.



I'm pleased that this procedure seems to have worked but I'm a little perplexed as to why I have run into the failure of the initial install (all identical failures) on several different machines. Is it something that I'm consistently doing wrong?



Thanks

Are you running SQL Server 2000?  Could you post the log file from the install?  It should be located in the C:\Program Files\Common Files\MicroFour\StrataFrame\ folder.

It was on another machine with the TCP/IP protocol enabled. I entered the IP of the machine hosting the database. It did let me in if I logged on as sa, but then the install failed.



I have since installed a local server (see my later request). The authentication problem was resolved but the install still failed at the same point.



Thanks

Are you running the install from a network share, or is it on your local machine? 

The SQL Authentication page of the install wizard is part of InstallAware, so I think we have limited control over it, but there might be something we can do...

I am running the installer on a clean machine. The SQL Server is on another machine. The SQL Management Studio can connect using Windows Authentication. The Strataframe installer can only connect if I use SQL Server authentication.

Is there some setting that controls this?

Does anyone have an idea why Windows Authentication would fail within the Strataframe context but succeed in the Visual Studio context?

Thank you