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
- :
- Re: SQL Scripts in a Patch
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
‎Jul 08, 2009
05:43 PM
SQL Scripts in a Patch
I have a really bizarre issue with SQL scripts in a patch that I'm running. Hopefully I can accurately describe the issue.
We have a SQL script that is run every time the installation is executed, and any time a patch is executed. This works fine.
We're on our fourth patch since our last CD release. Each patch is cumulative, and should be able to run against a previous patch, or since the CD release. In patch three, the SQL script was changed. A line was added to it. This worked fine.
Now if the user runs patch 4, and has yet to run patch 3, then the SQL script does not have the change in it. I've verified this by looking at the SQL script that is in the "Temp" directory.
If the user has patch 3 installed, then the correct SQL script is there.
If the user runs the full installation(ie, not the msp patch), then the correct SQL script is there.
I'm at a complete loss as to why the patch is behaving incorrectly, and it's hard to debug since the data is encrypted in the MSI tables. This seems like it may be a bug on Installshield's part, but I'm really having trouble figuring it out.
We have a SQL script that is run every time the installation is executed, and any time a patch is executed. This works fine.
We're on our fourth patch since our last CD release. Each patch is cumulative, and should be able to run against a previous patch, or since the CD release. In patch three, the SQL script was changed. A line was added to it. This worked fine.
Now if the user runs patch 4, and has yet to run patch 3, then the SQL script does not have the change in it. I've verified this by looking at the SQL script that is in the "Temp" directory.
If the user has patch 3 installed, then the correct SQL script is there.
If the user runs the full installation(ie, not the msp patch), then the correct SQL script is there.
I'm at a complete loss as to why the patch is behaving incorrectly, and it's hard to debug since the data is encrypted in the MSI tables. This seems like it may be a bug on Installshield's part, but I'm really having trouble figuring it out.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 09, 2009
12:42 PM
Is patch 4 built with upgraded MSI package 3, 2, and 1 provided as previous packages?
One possible issue is the patch transforms in patch 4 are not being correctly applied at runtime. Windows Installer determines which transforms are applicable based on 1) the set of transforms contained in a patch (there are multiple when there are multiple previous packages used to build the patch) and 2) the product and product version information contained in each transform's summary information stream.
If the patch was created with only package 3 (or some other) package as in the previous package list, the transforms contained in patch 4 can only be correctly applied at runtime if patch 3 (or some other patch) is already installed.
If the patch transforms in patch 4 are misordered, the wrong set of transforms could be applied.
An issue like this typically needs to be debugged with a verbose log of the patch installation to determine what transforms in patch 4 MSI is attempting to apply to the existing product state on a target machine.
One possible issue is the patch transforms in patch 4 are not being correctly applied at runtime. Windows Installer determines which transforms are applicable based on 1) the set of transforms contained in a patch (there are multiple when there are multiple previous packages used to build the patch) and 2) the product and product version information contained in each transform's summary information stream.
If the patch was created with only package 3 (or some other) package as in the previous package list, the transforms contained in patch 4 can only be correctly applied at runtime if patch 3 (or some other patch) is already installed.
If the patch transforms in patch 4 are misordered, the wrong set of transforms could be applied.
An issue like this typically needs to be debugged with a verbose log of the patch installation to determine what transforms in patch 4 MSI is attempting to apply to the existing product state on a target machine.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 09, 2009
01:38 PM
Yes, packages 1, 2 and 3 were provided as previous setups.
I'm really not sure about the ordering or how you change that. I wasn't aware that was possible.
I've attached a verbose log. In this case the patch numbers were simplified:
192 = Original
334 = Current(Patch 4)
319 = Patch 2
331 = Patch 3
I'm really not sure about the ordering or how you change that. I wasn't aware that was possible.
I've attached a verbose log. In this case the patch numbers were simplified:
192 = Original
334 = Current(Patch 4)
319 = Patch 2
331 = Patch 3
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 09, 2009
05:35 PM
MSI seems to be applying the first transform that seems valid:
Unfortunately, this transform (based on the numbers you've provided) only contains the differences from package 3 -> package 4. The following is the transform that is probably needed:
You may try the following as a test:
1. In the Patch Design view, select the item for previous package 3.
2. On the right-hand panel, select the Advanced tab.
3. Change the Version Relationship to "Previous Setup Version = Latest Setup Version".
4. Rebuild the patch configuration.
This may be related to the ordering of the transforms in the patch (unfortunately, I don't recall specifically what issues that causes). Ideally, MSI should start at the oldest transform and work to the latest, but it does not appear to be doing so in this case. This can be adjusted for if necessary through the ISTargetImage table in the project containing the patch config.
MSI (c) (28:3C) [11:11:25:562]: Looking for patch transform: ORD_2_2_1_331ToORD_2_2_1_334
MSI (c) (28:3C) [11:11:25:562]: Validating transform 'ORD_2_2_1_331ToORD_2_2_1_334' with validation bits 0x8a2
MSI (c) (28:3C) [11:11:25:562]: Transform 'ORD_2_2_1_331ToORD_2_2_1_334' is valid.
Unfortunately, this transform (based on the numbers you've provided) only contains the differences from package 3 -> package 4. The following is the transform that is probably needed:
MSI (c) (28:3C) [11:11:27:671]: Looking for patch transform: ORD_2_2_1_319ToORD_2_2_1_334
MSI (c) (28:3C) [11:11:27:671]: Validating transform 'ORD_2_2_1_319ToORD_2_2_1_334' with validation bits 0x8a2
MSI (c) (28:3C) [11:11:27:671]: Note: 1: 2748 2: ORD_2_2_1_319ToORD_2_2_1_334 3: C:\WINDOWS\Installer\619c8.msi 4: 2.20.4.1 5: 2.20.6.1
MSI (c) (28:3C) [11:11:27:671]: 1: 2748 2: ORD_2_2_1_319ToORD_2_2_1_334 3: C:\WINDOWS\Installer\619c8.msi 4: 2.20.4.1 5: 2.20.6.1
MSI (c) (28:3C) [11:11:27:671]: Note: 1: 2729
DEBUG: Error 2748: Transform ORD_2_2_1_319ToORD_2_2_1_334 invalid for package C:\WINDOWS\Installer\619c8.msi. Expected product version <= 2.20.4.1, found product version 2.20.6.1.
You may try the following as a test:
1. In the Patch Design view, select the item for previous package 3.
2. On the right-hand panel, select the Advanced tab.
3. Change the Version Relationship to "Previous Setup Version = Latest Setup Version".
4. Rebuild the patch configuration.
This may be related to the ordering of the transforms in the patch (unfortunately, I don't recall specifically what issues that causes). Ideally, MSI should start at the oldest transform and work to the latest, but it does not appear to be doing so in this case. This can be adjusted for if necessary through the ISTargetImage table in the project containing the patch config.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 10, 2009
12:19 PM
Thanks a ton man. Adjusting the ISTargetImage table seems to have fixed this issue. I'll have to do more testing of course, but at first glance, it appears to be good.