View Full Version : IIS and SQL supports are poorly implemented

06-16-2004, 02:00 PM

Please correct me if I am wrong.

IIS and SQL new features in InstallShield X are not fully architected and implemented. In fact, they are poorly implemented. There is a very very limited set of functions/procedures that allow run-time implementation. Followings are what I saw:

IIS do not support:
- FTP ( which is part of IIS ), and
- IIS extended procedures for IIS 6 and Windows 2003.

SQL do not support:
- Dynamically adding scripts during run time.
- creating new database.

All SQL scripts are inserted during design time, and attached to a component do not make sense. This architecture is too mature. It should at least allow the user to run list of scripts against a specified database.

Any ideas about any work around, or correction to my understanding would be greatly appreciated.


06-28-2004, 02:01 AM

I am not working on the IIS feature in InstallShield X, so let me answer your questions about the SQL Server feature.

1. Dynamically adding scripts during run time.
For security reasons, we encrypt SQL scripts that you specified in the SQL Server view when building into a setup. That is because InstallShield X allows you insert scripts only during the design time. If you can provide me with your business model where you need to insert scripts at the runtime, that would be greatly appreciative. We will consider how we can support your requirements.

2. Creating new database.
The InstallShield X SQL Server support always creates the database specified in a SQL connection if absent on the target server. In the first service pack, we will provide an option, 'Create Database If Absent' so that you will be able to turn on/off this behavior. You may want to uncheck the option when you create a database by running your custom code.

Hope this helps.
Hidenori Yamanishi
InstallShield Software Corp

06-28-2004, 12:44 PM
Hi Hidenori,

I really appreciate your concerns.

I was hoping that InstallShieldX ( InstallScript ) would ease my
SQL configuration jobs, but it is all static. What I am looking for
is a dynamically configuration.

My core installer will ask for:
- user name and password.
- database name.
- database properties, such as size, location, etc...
then it will either build a new database or upgrade the existing
database. All SQL scripts to be used are determined at run-time

All other installers will ask for the existing database properties, then, similarly decide what scripts they will execute or dispose SQL part(s) at all if all requirements are not met. The installer should also be able to query an existing database, and write some entries, too.

I have been using ADODB, and isqlw to do these tasks, but I thought it would be better if InstallShieldX InstallScript would
really help!!!

David Le.

07-09-2004, 11:23 AM

I appologize for tardiness in replying to your response. The SQL Server support of InstallShield X does not have the ability to accomplish your requirements. I submit a feature request work order #1-RILF5, so that we can consider it in a future release.

Thank you for your feedback.
Hidenori Yamanishi