This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Empty tables to be filled
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 28, 2013
06:56 AM
Empty tables to be filled
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.
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.
(13) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 28, 2013
07:24 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 03, 2013
03:24 AM
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).
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).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 03, 2013
05:46 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 03, 2013
10:55 AM
Please, you should not be advertising for WiX/DTF .
We are still in InstallShield Forum
We are still in InstallShield Forum
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 03, 2013
11:59 AM
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.
Both InstallScript and DTF generate Type 1 Custom Actions. Use them as needed.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 04, 2013
08:48 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 04, 2013
09:18 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 04, 2013
09:31 AM
============================================
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 04, 2013
10:00 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 04, 2013
11:35 AM
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):
So any other InstallShield/InstallScript suggestions would be appreciated.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 04, 2013
12:18 PM
Did you read the entire thread? MichaelU mentions an XML setting.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 05, 2013
04:51 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 05, 2013
06:50 AM
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.
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.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)