|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Alan,
As I think that you have already discovered, the logic you are expecting is already the way it works. So if you have any continued problems, please let us know. Thanks.
|
|
|
|
|
Edhy Rijo
|
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
Alan Jones (07/31/2009)
As for the multiple .bin files, I think our best option at the moment is two packages, one that deploys just the meta data and a second that is data only.I agree, this way you will have better control on the ending result if one of the package fails.
Edhy Rijo
|
|
|
|
|
Alan Jones
|
|
|
Group: StrataFrame Users
Posts: 7,
Visits: 32
|
You can disregard the previous post. There appeared to be some type of corruption in the package file where it wasn't copying out the DataDeployment.xml. Other package files appear to be copying it correctly. As for the multiple .bin files, I think our best option at the moment is two packages, one that deploys just the meta data and a second that is data only.
|
|
|
|
|
Alan Jones
|
|
|
Group: StrataFrame Users
Posts: 7,
Visits: 32
|
On a separate note, I've noticed when the deploy meta data runs, the DeploymentData.xml does not get pulled and created. Is it possible to pull and create that as well during the meta data process or is there some reason it is being omitted?
In our situation, we are deploying some rather 3 large package files, each with two to three .bin files around 2 gb. When our deployment program runs, it essentially creates those .bin files in the temporary folder twice - once for the metadata phase and again in our data deployment phase. (Since we are calling the above mentioned enumdeploymentpackages which opens the package again.) It seems like a lot of unnecessary overhead to be pulling those .bin files in both instances.
|
|
|
|
|
Kenneth Langley
|
|
|
Group: StrataFrame Users
Posts: 26,
Visits: 1.5K
|
Well Done. We are not using 1.7 release yet. We have a release pending and have locked the code. We will make this change to the DLL and use this for our deployment on the install CD. After this release we can move to 1.7 and get the fix from you then. By the way we have moved to InstallShield from InstallAware. It was just not cutting it for our install requirements. Thanks Kenneth
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
I see one place in the code not setting the package to be Read-Only (and will b ea 30 second fix), but before I can just send you a DLL, what version are you on? If you are not on 1.7, then me sending you a DLL to try won't work. In this example, you will need to just open the 1.6 SF code, make the change in the EnumDeploymentPackages method, and then use that assembly and then the next update will address this (so you don't have to maintain the source code). In the DatabaseMigrator class in the DBEngine, the code should look like this to ensure it is opened as Read-Only (EnumDeploymentPackages method): '-- Establish locals
Dim laReturn As New List(Of DeployDataInfo)
Dim loPackage As New PackageFile()
Dim loRow As DataRow
Dim loItem As DeployDataInfo
Dim loDeployDataDS As DataSet = Nothing
loPackage.FileOpenAccess = System.IO.FileAccess.Read
loPackage.Open(MetaDataPkgPathAndFileName, True, False, PkgPassword)
'-- Iterate through the records in the deployment data of the server and get them
loPackage.ExtractFiles(loPackage.GetIndexesByFilename("DeploymentData.xml"), PackageExtractionType.Relative, GetTemporaryFolder, True)
'-- We're done, so close the package file
loPackage.Close()
Once that change is made, the error should go away. I will make that change on this side, but if you are not on 1.7 then the change will have to be made on your side as well. If you don't get it going, let me know and I will go back in history and get the 1.6.6 build sucked down.
|
|
|
|
|
Kenneth Langley
|
|
|
Group: StrataFrame Users
Posts: 26,
Visits: 1.5K
|
Here is the code that we are using. Do you have any suggestions for a change ? ''' <summary>''' Assumes that the meta-data has already been deployed and will deploy the''' deployment data packages within the package file.''' </summary>''' <remarks></remarks>Private Sub StartDataDeploymentPhase()'-- Establish LocalsDim laPKs As New List(Of Integer)Dim loItem As DeployDataInfo'-- Build a collection with all of the deployment primary keys. For Each loItem In DatabaseMigrator.EnumDeploymentPackages(_Package, "sunshine")laPKs.Add(loItem.PrimaryKey) Next '-- Create the DatabaseMigrator instanceIf _SQLUserName.Length = 0 Then_DatabaseSetupData = New DatabaseMigrator(_SQLServer, True, Me)Else_DatabaseSetupData = New DatabaseMigrator(_SQLServer, False, Me, _SQLUserName, _SQLPassword)End If'-- Set the Logfile location_DatabaseSetupData.LogFilePathAndFileName = MicroFour.StrataFrame.Strings.StringBasics.AddBS( My.Computer.FileSystem.SpecialDirectories.Temp) & "tcms_install.log"Me._DatabaseSetupData.EnableLogging = True'-- Create the DatabaseTargetName ArrayCreateDatabaseTargetNames() '-- Start the deployment of the dataMe._DatabaseSetupData.DeployData(_Package, "sunshine", laPKs.ToArray(), Me._DTNames)End Sub
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Ken, You can already do exactly what you want. If you are going to use the standard meta data deployment class, then we will have to make a change to that dialog, but I went back and looked at our notes and we added the ability to open as read-only specifically for you for this purpose. Here is the code to open a package file as read-only: PackageFile x = new PackageFile();
x.FileOpenAccess = System.IO.FileAccess.Read;
x.Open(@"C:\Temp\StrataFlix.pkg", true, false);
x.Close(); I reproduced the error you received first, then I executed the code above and it opens as advertised.
|
|
|
|
|
Kenneth Langley
|
|
|
Group: StrataFrame Users
Posts: 26,
Visits: 1.5K
|
Here is the Stack trace error.
|
|
|
|
|
Trent Taylor
|
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
What is the stack trace that you are getting? It sounds like it is trying to extract something to the source drive, which doesn't sound right. If you don't mind, post the stack trace so I can see where it is being called. Thanks.
|
|
|
|