StrataFrame Forum

Data Deployment Package file problem

http://forum.strataframe.net/Topic23929.aspx

By Alan Jones - 7/28/2009

Hey guys,
    I've ran into an issue deploying package files from a dvd.  The meta-data phase works smoothly, but then errors when attempting to deploy the actual data.  The error message is 'Access to path D:\mypackage.pkg' is denied.

I was able to get around this by changing the code in DbEngine -> DatabaseMigrator -> EnumDeploymentPackages where it was attempting to open it with FileAccess.ReadWrite (the default for a new PackageFile). 

from:
Dim loPackage As New PackageFile(MetaDataPkgPathAndFileName, True, False, PkgPassword)

to this:
Dim
lopackage As New PackageFile()
lopackage.FileOpenAccess = FileAccess.Read
lopackage.Open(MetaDataPkgPathAndFileName,
True, False, PkgPassword)

Any chance of including this in your next update/release?


 

 


 

By Trent L. Taylor - 7/29/2009

Actually this isn't an issue. There is another thread or two out here about this, but it has to do with the access to the PKG file already being open via the previous process. Just FYI, this is something that we do as well and so I am very confident in this process.



One thing that you can do to make sure that the issue is resolved is to totally close the DatabaseMigrator class and re-created it and re-open the package. So when the meta-data is completed, you will close the migrator, re-create it and then start the data deployment phase. This is one way to ensure that the PKG file is not being held open.
By Kenneth Langley - 7/29/2009

We implimented the recommendations you explained. We are not having an issue with the package file being open but that the file cannot be opened from a read only drive. If I make my directory "with the package file" on the harddisk readonly, I get the same error as if it were on a DVD.

This happens when we try to deploy data, not metadata from same package file.

What do you think about this error ?   w00t

TIA

Kenneth

By Kenneth Langley - 7/29/2009

We have also checked the data deployment through the DDT and we are getting the same issue. I believe that when you are opening the package for data deployment that it is trying to open as readwrite.

Make a package file readonly on your machine. Try to deploy data from said package file. You will get the same error from the DDT.

Error message below:">

By Trent L. Taylor - 7/29/2009

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.
By Kenneth Langley - 7/29/2009

Here is the Stack trace error.
By Trent L. Taylor - 7/29/2009

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.
By Kenneth Langley - 7/29/2009

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 Locals

Dim 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 instance

If _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 Array

CreateDatabaseTargetNames()

'-- Start the deployment of the data

Me._DatabaseSetupData.DeployData(_Package, "sunshine", laPKs.ToArray(), Me._DTNames)

End Sub

By Trent L. Taylor - 7/29/2009

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.
By Kenneth Langley - 7/29/2009

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

By Alan Jones - 7/31/2009

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.

By Alan Jones - 7/31/2009

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. 

By Edhy Rijo - 7/31/2009

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.
By Trent L. Taylor - 8/3/2009

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.