I have the problem and I'm trying to resolve it by following this link
https://support.microsoft.com/en-ca/kb/969052
However, when it says
"To complete the steps in this procedure, you have to copy the FindSQLInstalls.vbs script from the "More Information" section to a local folder on the computer where you are trying to update your SQL Server installation."
I'm confused on how to find this "FindSQLInstall.vbs" file and how to run it.
I'm just a beginner, so any help would be greatly appreciated.
I encountered this error while trying to put SP3 on SQL 2008 R2. Some research lead me to the same article https://support.microsoft.com/en-ca/kb/969052 and the FindSQLInstall.vbs Script.
I also do not have a lot of experience with command prompt or .vbs I do have some coworkers who have previously worked through the same issue. If you have found the Microsofts kb/969052, in theory everything you need is there. But if you are like me you need a bit more. This is what I did.
Note that I was VERY Lucky, We have a share folder where we keep copies of all of the upgrade/updates that we install. The .vbs found and copied many of my missing things (though it took me a while to figure that out)
Create folder on the server for working on issue 'C:\Repair_msi' = This puts all my housekeeping in one place
Save FindSQLInstalls.vbs script from https://support.microsoft.com/en-us/kb/969052#bookmark-script in this folder
Create text doc, paste in the script and rename as 'FindSQLInstalls.vbs' you will probably need to show hidden extensions to convert from .txt > .vbs
In command prompt type cd C:\Repair_msi = cmd working in this folder
In command prompt type Cscript FindSQLInstalls.vbs ServerName_sql_install_details.txt
Open the new document 'ServerName_sql_install_details.txt' which is now in this folder
The document says the .vbs found and copied over several missing .msi files
Missing cache file replaced by copying....
Previously missing package C:\Windows\Installer\67fe40cc.msi now exists in the Installer cache.
Validated that .msi files that were reported as missing on first error, have been identified by the .vbs and are now in C:\Windows\Installer
DOES NOT exist, directions do occur, called out with
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!! C:\Windows\Installer\4541a.msi DOES NOT exist in the Installer cache. !!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The path called out in action plan is temp folder on the PC of a coworker who did a previous install, no hope of recovery from there.
No action taken
Rename 'ServerName_sql_install_details.txt' > '1-ServerName_sql_install_details.txt'
In command prompt type Cscript FindSQLInstalls.vbs ServerName_sql_install_details.txt = Run the .vbs again
Open the new document 'ServerName_sql_install_details.txt' which is now in this folder
New document is essentially the same as old, except it now says the previously missing .msi are now present and gives some direction if you still get errors on update
The 'DOES NOT exist' item still exists. I used crtl+F to search the document and this is the only required thing listed.
Copy "C:\Users\NAME\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\LWRNT0CZ\SQLServer2005_BC[1].msi" C:\Windows\Installer\4541a.msi
We have a folder with pretty much every SQL install and upgrade, on searching I find multiple SQLServer2005_BC.msi but no 4541a.msi
More reading and I learn that we need to find the correct version of SQLServer2005_BC.msi; copy and rename it to 4541a.msi
Can't find version numbers for the 30+ versions we have on the share....
Maybe we don't really need that one?
Try the SP install, It does not error out, I get to the Install now step (first attempt errored very early)
Pending off hours time slot to apply SP to this production server
In summary
It turns out I could have just run the FindSQLInstalls.vbs Script and then run the SP install again. The .vbs will return results which include the place the file was when it was last used as well as the version number. If the .vbs does not find it there, you will need to find what it wants, copy it and rename it with the correct name and put it the correct place.
Related
I have an c# wpf application and an additional installer project to create an installer of the application. Among many other files, the installer project has a installer.cmd file (I took over it from someone else) and a Product.wxs file. I was able to create an installer by running msbuild tools\installer.cmd /P:Library=net461 /P:Platform=x64 command on the developper comand prompt.
I was trying to create a desktop shortcut in all user's desktops and was playing with *.wxs file for that. I know you guys will roast me because of the following sentence but I don't know what else can I say. Something I did break something and somehow the msbuild starts to give error. I cannot say what I did because I tried many different things.. I went back to original project but it didn't help. So what is done is done. I will talk about the error now.
The error itself doesn't tell much:
C:\workspace\QToolInstaller\tools\installer.cmd(117,5): error MSB3073: The command "nuget Source Add -Name PkgSrc_638107674121812897 -Source C:\workspace\QToolInstaller\exports" exited with code 1.
I checked online to understand this error code but there wasn't much. However there is another line just before this erorr line:
The source specified has already been added to the list of available package sources. Provide a unique source.
Well, this wasn't in usual warning color or marked as a warning. But I think it is worth to investigate.
So the "source" mentioned here is PkgSrc_638107674121812897. I scanned the installer.cmd to see where is this coming form and saw that this file is named by using time ticks as:
<LocalSource>PkgSrc_$([System.DateTime]::UtcNow.Ticks)</LocalSource>
Although I ran the msbuild command multiple times, the name of the source is always different. I ran the command in diagnostic mode by using -verbosity:diag option. And I checked the file name among all the logs. There is no match. I tried to change the name to something ridicolous that cannot be listed anywhere but got the same error. Removed alll the files, created them again, restarted the PC etc. Nothing have changed. This name is really unique and but still I am getting this message. I wish I had logs form previous successfull runs. I cannot tell if this is the cause of the failure or not. Does any of these ring any bell fellas?
It is solved! Luckily a colleague of mine have faced with this before. I hope no one will have to deal with this problem again.
So apparently there is a bug(?). Altought that name is unique it thinks the opposite. When I do list the sources with thw followng command
nuget source
among the one that should be there, there is one extra line as PkgSrc_638107643440982987. Although my installer.cmd suppose to remove the source every time after it is done, it didn't for once. And although the new source is named differently, it doesn't care and gives that non-warning, non-error message followed by a meaningless error code 1 message. How to solve it?
We tried to remove the source by command prompt like this:
nuget source delete -Name PkgSrc_638107643440982987
But it is not deleted. So we went to the Visual Studio->Tools->NuGet Package Manager->Package Manager Settings->Package Sources. Found the guilty source and remove it. And then it is resolved.
So, I have a WIX project which is to install either fresh installations or over previous installations of a product. This product, if it was already installed, has several files inside of 3 different folders which need to be preserved. This project also needs to copy the contents of those 3 different folders into another set of folders (same content in two different locations). In order to accomplish this I have set up my project to first attempt to write into the original folders if the files don't already exist, then copy the contents of those folders. On an upgrade where those files already exist this works fine. On a fresh install the second set of folders do not get created, but all the files do.
My assumption, and I may be incorrect, is that the msi is attempting to copy the folders over before they have even been created. This would cause folders to not exist in the area they were supposed to be copied to as there would be nothing to copy from. Is there a way I can ensure the files have been generated before trying to copy them? Is there a better way of going about this that I'm not seeing?
EDIT:
I'm going to try to clear this up a little. What I'm trying to do is the following (pseudo):
1) See if an option file (hi.opt) exists in c:\options, if not create it.
2) Copy that file to c:\options\opt2015.
I'm doing this 3 times for 3 different folders. I am creating the initial files with Wix in the c:\options folder using the NeverOverwrite parameter. This part works great; the files are created without issue and none are overwritten if they already exist. Where the problem lies is step two where I'm using the CopyFile Wix command. This will only copy some of the files from the c:\options folder to the c:\options\opt2015 folder. Depending on the initial setup of the system (if the files at c:\options exist or not) some files will copy over and others won't. It's not random, the results are repeatable every time, but there seems to be no reason why some files copy and others don't depending on the initial setup of the system.
I hope this makes sense and is a little more clear, though I think it makes things worse! It is strange behavior because to me it looks like everything should just work, but it doesn't (isn't that every bug though).
Edit2:
After more work and creating a vb script which runs perfectly outside of WIX my team and I have determined that the files just are not being seen by WIX during the installation even though they do exist. We haven't found any permissions issues and the installation is running as admin on an admin account. Doing the copy via a VBS or through the Wix CopyFile command results in, well the same results; files that already exist on the system are not being copied. Any more ideas? Should we find a solution I'll be sure to post it because this is just getting weird.
I believe your installer design should work as long as you're attempting to copy the files after the InstallFiles action runs. You should be copying the files from the first set of folders to the second set of folders by doing one of the following:
Running a deferred custom action that executes after InstallFiles
Using the MoveFiles action
This is too long for a comment, but may not be an answer either....
There isn't really such a thing as "over previous installations of a product", especially if you end up with multiple instances in Programs/Features, and files that may or may not have the same component ids replacing each other - that's going to be a mess. If you need to upgrade the installed product, use a major upgrade, that seems to be where you're going with this. If you are already writing custom actions to do some of this "first attempt to write into the original folders" then I've no idea what's going on or where you doing this in the install. In general, if you need those files in the new install then add them to the new major upgrade MSI. If you need to copy the older existing files from the older product, then do a major upgrade with afterInstallExecute and write custom action code to copy them before the InstallFiles action. Or the CopyFile WiX element could do it, see the part about the element under a component with no fileid.
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
Well, as sometimes happens, the error was entirely elsewhere. It turns out that an uninstaller for another program which was in the chain of programs which are installed at the same time was destroying the folder. Unfortunately this is what happens when a product isn't touched for 10 years. Thank you for your contributions, they were very helpful. Even though I was going down the wrong path the whole time I still made use of them in my tests and am more adamant about checking the installation order.
Right now we have a program that opens all of the word files in a folder and adds some information to the footer. After switching from Windows XP and Word 2003 to Windows 7 and Word 2007 we have started getting the following error:
Run-time error '5096':
EOALPHABETICARABICARABICABJADARABICALPHABAHTTEXTCAPSCA
(c:\Users...\Content.MSO\8BE508C6.docx)
It occurs at random in any of the files (you can be 10 files in or 100). I thought that it might be a problem with the files being on a network drive so I modified the program to copy each file locally first, add the footer to that copy, and then copy it back out to the network. However, that didn't seem to work. I'm looking for any suggestions on how to fix the problem or possibly rewrite the solution. However, I need to keep the solution in VBA since this app is part of a bigger suite which in not ready for a .NET re-write.
As it turns out I was able to workaround this problem by copying the word files locally, running the main code on the local copies, then copying them back out to the network. It didn't seem to be working at first because the user's machine on which I tested it did not have the most recent version of the program.
Adding this note for those still looking for answers to this error...
I have a macro that creates several docs from one that is open based on sections in the main document.
I was getting the Run-time error '5096' and was an able to find any solutions that worked.
Upon further examination while debugging the code I discovered that while pulling data out of the main doc and building a file name that there was a carriage return after the file name and before the extension. After adding a replace statement to remove carriage returns I am able to process documents all day without an error.
I have found that the error is caused by the total number of characters in the file name is too long. This usually occurs when manipulating file names and the full path is set in the variable. I will manually chop pieces out of real long names to force it to work.
I suppose if I were smart, I'd move into the directory and just deal with the file names without the directory prepended to the name.
Does anyone know how to get hold of the path to the directory where the LINQPad script file (.linq) resides?
Or to the script itself for that matter.
Note that I'm not talking about the location of the "My Queries" folder, the one shown inside LINQPad.
I can save a .linq file anywhere on disk, and open it by double-clicking on it.
For instance, if I save the file to C:\Temp\Test.linq, and execute the program, I'd like to have either C:\Temp or C:\Temp\Test.linq.
Basically I'd like something akin to Environment.CurrentDirectory or Assembly.GetEntryAssembly().Location, just for the .linq file.
Things I've tried:
Looking through environment variables
Looking through the LINQPad assembly that is given to my script
Throwing an exception and looking at the stacktrace (contains a link to a temporary copy of my script somewhere else)
Environment.CommandLine.Dump(); - gives LINQPad executable
Environment.CurrentDirectory.Dump(); - gives C:\windows\system32
Assembly.GetExecutingAssembly().Location.Dump(); - gives temp directory
I've just added a feature to address this. You can test it now by downloading the 2.27.1 or 4.27.1 beta build.
To get the current query's folder, use the following expression:
Path.GetDirectoryName (Util.CurrentQueryPath)
I presume you mean programatically and not through the UI itself.
The path to the linq file directory is held in
%APPDATA%\LINQPad\querypath.txt
The next question after "How do I get LinqPad script directory" is "How do I set it?" below is how you do it and link to where I found the answer
Directory.SetCurrentDirectory (Path.GetDirectoryName (Util.CurrentQueryPath));
I'm trying to use the VssGet task of the MSBuild Community Tasks, and the error message "File or project not found" is beating me with a stick. I can't figure out what in particular the error message is referring to. Here's the task:
<LocalFilePath Include="C:\Documents and Settings\michaelc\My Documents\Visual Studio 2005\Projects\Astronom\Astronom.sln" />
<VssGet DatabasePath="\\ofmapoly003\Individual\michaelc\VSS\Astronom_VSS\srcsafe.ini"
Path="$/Astronom_VSS"
LocalPath="#(LocalFilePath)"
UserName="build" Password="build"
Recursive="True" />
If I write a Streamreader to read to either the database path or the local path, it succeeds fine. So the path to everything appears to be accessible. Any ideas?
Two thoughts. One, sometimes a type load exception manifests as a FNF - let's hope that's not it. But if the code is actually being honest, you can track the problem using Procmon or Filemon. Start one of those utilities and then run your task again. You should be able to track down a record of a file that couldn't be located.
#famoushamsandwich that's a great response -- I had not previously heard of procmon or filemon. Tried procmon on the problem, but even after sifting through the relevant output (my gosh the machine does a lot more stuff behind the screen than I was aware of) I couldn't find where a file I'm referencing wasn't being found.
Procmon and Filemon are good suggestions - just make sure you filter the results to only show errors. Otherwise the success messages will bury the problem entries. Also, you can filter out processes that are not at fault (either through the filter dialog or by right-clicking the entry and choosing "Exclude Process".)
A couple other thoughts:
In the LocalFilePath, you are specifying a single file as opposed to a folder. The task, on the other hand, specifies to get files recursively. Perhaps you need to remove "\Astronom.sln" from the LocalFilePath?
Is the build task being run under your account or another? It's possible you have a permissions issue
Do you already have a copy of the code pulled down in the same location? Perhaps there is a failure to overwrite an existing file/folder?