Empty tables to be filled

[jonathanqis]

I get an error ERROR_BAD_QUERY_SYNTAX (1615) when I call MsiDatabaseOpenView with a query on empty tables.
I'm using this call to get the handle to the view. That handle is not set up after the call.

I wish to dynamically fill the tables ServiceControl, ServiceInstall and Registry with information found whilst running a major upgrade / install product crossover.

Reading this link:
http://community.flexerasoftware.com/showthread.php?161797-ISSetAllUsers-appears-to-hang-IS-12/page6&p=361243#post361243

I think the problem may be that empty tables are being removed from the final setup.exe (msi there in).

Can anyone please confirm this is the cause.

I don't think that putting some dummy values in the tables is the right way to solve the problem.

Is there a way to prevent specific tables being removed when the install file is created (if this is indeed the problem) ?

OR

Is this a bug in the behaviour of InstallScript. It is after all possible in SQL to return an empty recordset (the direct equivalent of my actions).

This is a bit of a show stopper right now so I'd really appreciate any ones information/suggestions to solve this issue.

Thanks in advance.

[Christopher_Pai]

Please see:

http://community.flexerasoftware.com/showthread.php?204839-Preserving-unused-tables-on-compile

BTW, if managed custom actions are a possibility for you, using WiX's DTF to write custom actions in C# is way way easier then InstallScript. The Microsoft.Deployment.WindowsInstaller interop library has classes that greatly simplify the MSI API.

[jonathanqis]

We are not developing using Wix.
We need an InstallScript solution.

I don't believe this should be a hard fix.
I think I may just be missing a configuration option for the compile/build or there is a better place to do the addition of lines to the tables.

This is after all not an unusual action to do (adding custom data to an install).

[Christopher_Pai]

Did you read the thread that I linked? It tells where that setting can be found.

My point about WiX/DTF is that it is far easier then InstallScript and can still be used in an InstallShield MSI.

BTW, yes, it is unusual. The vast majority of setup developers will never even stop to think that it is possible to dynamically author installer logic at runtime. It's like CodeDom and Reflection in .NET.

Even fewer will realize that technologies from different tool sets are interchangeable due to the underlying technology that they share.

[Roman1]

Please, you should not be advertising for WiX/DTF .
We are still in InstallShield Forum

[Christopher_Pai]

Open your mind. I'm not advertising for WiX, it's a free and open source project. I'm advocating taking some of their technology (nothing wrong with that) and using with InstallShield. IOW I use WiX to add value to InstallShield, not to replace it.

Both InstallScript and DTF generate Type 1 Custom Actions. Use them as needed.

[jonathanqis]

I'm with Roman1.

It is not helpful to keep going on about Wix etc. I thought I made it clear in the opener that this was an InstallScript project.

When I ask about tea, I'm not interested in what varieties of coffee are available.
When I'm open to alternatives that will be stipulated in the question.

[Christopher_Pai]

You do realize that "InstallScript Projects" are not Windows Installer based, correct? There is a difference between InstallScript in the context of a project type and InstallScript in the context of an MSI custom action. In the former, WiX would have no role. In the latter, InstallScript is merely encapsulated as a Type 1 Custom Action and other implementations can be substituted.

It's obvious to me that the both of you are not at a technical level to understand this so perhaps one day you will. Good luck to the both of you.

[Roman1]

============================================
It's obvious to me that the both of you are not at a technical level to understand this so perhaps one day you will.
Good luck to the both of you.
============================================

Dear friend, your objective mind seems to be at the end.
Therefore, you reach to insults.
It is not the fine English kind.

[Christopher_Pai]

Roman,

You do as you wish, but do you not think you were insulting in accusing me of shilling for WiX and claiming that I should not post such things here? I'm sorry but I've earned the right to express my opinion around here.

Also, I know for a fact that people from WiX and InstallShield talk on a frequent basis. The point is it's not InstallShield vs WiX, it's InstallShield with WiX. We are all in it together on the Windows Installer platform.

Regards,
Chris

[jonathanqis]

May I point out that this is not a debating society meeting. I'm trying to find a workable solution to things that are required for business.

I'm not interested in opinions, it's information towards a solution I seek.

btw. I tried the release flag (which seems to be about directories not tables). Unfortunately it did not solve the problem which is :

I get a ERROR_BAD_QUERY_SYNTAX returned to the following query if no rows are in the table (i.e. works with available rows):

MsiDatabaseOpenView(hDB, "SELECT * FROM `ServiceControl`", hViewSC);

So any other InstallShield/InstallScript suggestions would be appreciated.

[Christopher_Pai]

Did you read the entire thread? MichaelU mentions an XML setting.

[jonathanqis]

Yes, changing the settings.xml file did stop the three tables i'm interested from being removed and my script does not report the error any more.

But that type of solution is InstallShield install specific and you would have to make note of that customisation so that future installs don't lose this customisation.

Would be a lot better if that were a setting in the GUI (e.g. against the table) and saved with the project.

thanks

[Christopher_Pai]

Yes, that would be a great feature. I know a tool that has that.... but you don't want to hear about it.

As for InstallShield, the trick I sometimes use is to create a fake component with fake data and put a condition on it that always evaluations to false. This way the compiler picks it all up but it is never acted upon.