I have an MSI file that contains several .sql script files, can anyone tell me if it is possible to extract these file and look at the content. I tried using orca to export the ISSQLScriptFile table, but the files were exported as .sql.ibd, which is useless.
Thank you!
I haven't looked at this in a long time but as I recall it's all encrypted.
https://community.flexerasoftware.com/showthread.php?188927-Extract-packed-script-sql-from-msi
"For security, the script is encrypted and then stored in the MSI package."
Someone then mentions that you can intercept the SQL files from a temp directory while the installer is running.
MichaelU could weigh in if this is still true and if there are any other work arounds.
Assuming that the files are inside the MSI file in the sense of being in the internal CAB file, then do an "administrative" install, which is not an install at all. A typical command would be:
msiexec /a [path to msi file] TARGETDIR=[path to a folder where the files will go]
It extracts all the separate files to that location.
Related
Unable to install SQL Server (setup.exe). Exit code (Decimal):
-2054422498Exit message: The specified directory, "C:\Program Files\Microsoft SQL Server)", for the INSTALLSHAREDDIR parameter is not valid because this directory is compressed or is in a compressed directory. Specify a directory that is not compressed.
I have already unchecked the Compress contents to save disk space option in advanced properties of the folder as suggested in another similar questions here.
Please help me figure out the solution to install SQL Server.
You have to remove compression.
Like I asked in the question, I had already unchecked the Compress contents to save disk space option in advanced properties of the folder however the same changes were required in the parents folder too (topsail's comment).
So I repeated the same steps as shown MBuschi's answer to the parent folder too and it worked fine.
I want to know if it is possible to restore my database without dump.
In fact, I had a problem with mysql on my debian 9 server. I uninstall debian and reinstate it. I lost everything but before uninstall debian, I saved ib_logfile0, ib_logfile1 and ibdata1 files and the database folder with the database name. There files and folder was located in /var/lib/mysql
I already tried to copy and paste the files and the folder on my new debian but it doesn't work...
Is it possible to restore the database with this 3 files and this folder (on the folder, there is .frm and .ibd files) ?
If you have the entire folder, then you effectively have the entire dataset. The two things that are elsewhere:
The MySQL code -- It would be wise to install the same version 5.xx.yy.
The config file(s) -- /etc/my.cnf (or wherever). You may have to reconstruct it. The one tricky setting (if you had changed it) is innodb_log_file_size.
I am not sure if there are other critical files in the directory other than the 3 files you mentioned.
Give it a try.
I have SSIS package and on VISUAL STUDIO working good, for another server pre production also, but when i use production server and try loading xls files nothing do, didn't see any files. I hv the same permission both server sql so i Somebody can help me? I will be maximum enjoye if somebody will react!
Thank you very much for the suggestions!
My package imports xls files into a database on sql server
In the package I have a foreich loop cointainer and in the directory I use the variable " input folder path" .In the expression on my menager connection i have variable "Full Path" (with file name)
On preproduction server, the package is great and loads xls files. On production server no. And i have comunicat :"For each file enumerator, no files were found that matched the file pattern or the specified directory was empty."
I set delay validation (connection manager, task) is true, When i deploy on server my project again, the message "another user uses files" Nobody use this folder. only me.
I Use the mapped path // fileserv / clientspath.filename.
I do not know what else i can write about this will be help self ..
I'm posting this rather odd issue here in the remote chance that someone has come across this before, or possibly just has an idea or two about what I could try or check next because I'm stumped.
Summary: SQL 2008 SSIS package tasks that attempt to create files with .zip extension fail with
"Access to the path is denied"
Detail: This first occurred in a test environment with a package that works fine in Dev (and Prod). The part that makes this problem odd is that it is all about the File Extension, not security. I mention this now to curb replies about checking the security (SSIS Account, Directory Level permissions etc.) :- it's not that, 100%.
So, I've built an SSIS package as a proof of behavior, that takes 3 files (a.txt, b.txt, c.txt) and respectively for
(a) uses CozyRoc Zip to Create a Zip,
(b) uses a script task to create a .zip (using GZipStream - I know this creates a GZIP not a ZIP but bear with me...) and
(c) native SSIS File System Task copies the file from c.txt to c.zip (yes, creating a .zip file that is not really a zip file).
All Three fail with the above message - the .ZIP files are created for (a) and (b), but remain at 0 length. (For (c) just the error message).
Now, I edit the SSIS package and change the extensions of the destinations (to .ZOP or .ZIP2 or .GZ or .ANYTHING), and all 3 work perfectly. And this is obviously how I know that it's the .ZIP extension not a "normal" security issue.
So I've initially assumed this is a one-off on this test server because it was the only place it happens, but I've found another box (build rehearsal) on which exactly the same problem exists. I've tried associating .ZIP with various different programs (Windows Explorer, WinZip, 7Zip, WinRar & "no program") and nothing works, and I've googled the problem to death with no luck yet.
I've tried creating .ZIP files with the various installed archive programs using their GUIs and they all work fine. Existing .ZIP files can be unzipped using CozyRoc. Existing .GZ (GZIP) files renamed to .ZIP can be unzipped using the script GZipStream decompress. And I can rename files to and from .ZIP using SSIS or Explorer/CMD. It's just SSIS (specifically SSIS) creating a file with extension .ZIP (specifically .ZIP) throws this error.
I'm starting to suspect it might have something to do with SSIS thinking that .ZIP is an archive "folder" not a ".ZIP File" but I don't know where to go with this idea, proving it or fixing it.
Any ideas at all? - at my wits end!!
Thanks in advance
P.S. The "obvious" answer of using .ZIP2 and renaming is not an option, there are (literally) hundreds of packages running in production that create .ZIP files and packages need to move from Test to Prod without modification. I really need a solution, not a workaround, in this instance if there is one.
This turned out to be a RedGate tool (HyperBac) having a file association with .ZIP extension files (amongst others). Hyperbac's monitoring of .ZIP files appears to have clashed with SSIS's attempt to write to the .ZIP file, as procmon reported shared file access violations, causing a spurious ACCESS DENIED error to be reported by the package.
Since use of the tool is necessary on our environments, I was able to solve the problem by deleting the .ZIP association using the GUI ("Hyperbac Configuration Manager" > "Extensions" > Ext=.ZIP, Delete)
I am writing a wix installer and I have used it to create a sql database.
We have a custom command line tool that we need to run to populate the database with its schema and data, the tool requires sql scripts to be included, we have quite a few and they are organised into various directories.
Is it possible to include these files in the installer and then run the command line tool against these files without having to copy these files to the install target dir.
I'm thinking perhaps I will have to copy these files to temp and then after install is finished clean them up, is there a better way?
You can create an msi custom action and embed sql scripts as resources within the dll itself.
Then schedule your custom action to run the exe on those sql scripts.
The msi engine will automatically extract and cleanup your custom action binaries.