We have a SharePoint server that is version something like 12.0.4 and we are trying to import a site collection that was exported from another SharePoint server. The version there is somthing like 12.0.0. We have the export but we no longer have access to the server. How do we import the site from a lower version into a higher version?
We have tryed the stsadm import function but that is where we get the problem with the version mismatch.
has anyone experenced something like this?
Maybe there's a better way, but here's what I would just do because it can be done in the background, simultaneously to doing other stuff...
OK, both are version 12, so that would probably be just a diff in Service Pack levels / hotfixes etc. Set up your clean SP environment anew, without any service packs, updates, patches etc. Check the version number. If lower than your export, gradually perform updates until the version number is just identical. Import, and only after testing your imported content optionally apply other updates as you see fit.
And you don't have access to the original content database either?
If you do have that, simply attach the content database from stsadm and it will upgrade the database for you on the fly.
Check out this article for a detailed list of what version numbers correspond to which updates and patches of SharePoint.
http://www.mindsharpblogs.com/penny/articles/481.aspx
Can you check the actual version numbers in your farm? 12.0.0.4 corresponds to the RTM and Beta versions of SharePoint.
Let us know the exact version numbers on both ends if possible (if the text is in the error), and maybe we can recommend a more detailed solution.
Related
i just want to ask about Visual studio doesn't detect my microsoft.ace.oledb.12.0..
last month i write a code to import from excel into database using VB.NET and it worked..
but after a month i open back my coding and try the system but it said that "microsoft.ace.oledb.12.0 provider is not registered" even though i already install microsoft access database engine 2010 before..
i never change a little bit of my coding..i just left it but now it doesn't work like before
is there any particular update or something that make it doesn't work??
thank you
Try changing your target cpu in your project properties. go to solution explorer<properties<Compile uncheck the prefer 32-bit or change to x64. It works for me, if it doesn`t work try searching a bit more iirc that question is already answered but i cant remember if it is in stackoverflow or other website, which has many suggestions
The Access engine can be installed as either 32-bit or 64-bit. As the other answer notes, it is important to make sure that your application matches the bitness of Access. You can check on installed OleDB providers by checking the Windows registry; you would need to search on all of the keys in HKCR/CLSID (under Wow6432Node for 32-bit), looking for entries with a value named OLEDB_SERVICES. Keys with this value will have the provider name as the default value. This (obviously) isn't practical to do manually, but it should be fairly straightforward to do programmatically.
We are maintaining code for one of our clients.
Initially, we copied all the source code that they have and added it to our TFS 2012.
We modify the code any time they need a bug fix and give the client deployment packages.
Now, client wants all the latest code in their TFS 2012 as well.
Is there a way to update their source code with our changes? ...
preferably automatically (i.e. power shell script) and preferably with history of changes.
There are many approaches each with some pros and cons. The following are the main options I would suggest.
Database backup and restore
This is the only path that guarantees full fidelity. It has some technical difficulties (e.g. SQL Server version and editions) and political (how much information you care to expose, how much effort you want to put in sanitizing your data).
Project synchronization
There are some tools, most notably the Integration Platform, that use the API to read and reply the changes from one system to the other. It requires that the syncing tool can see both systems via HTTP(S).
It gives you the flexibility to project only some data (say source code not work items).
Keep in mind that you will always loose something in the process: the Changeset number will never match, some users details.
Dumb dump
Give up conserving full history and be content to share the code.
This is the simplest to implement: get all the code, ship and check into the other system. You can associate release notes in the check-in.
Two simple scripts using TF.exe is all you need.
You can use TFS Integration Tool to achieve the code migration(TFS-to-TFS). TFS Integration Tool moving data between two different servers. The migration is done through the APIs of TFS, and there also some limitations.(Check the above link for more info)
Detail steps please see my answer in this question: Move Team Project to another Project Collection TFS 2013
I am using InstallShield X - professional Edition, version 10.0
I have created .exe file through installshield Basic MSI project and installsed it. During installation it extract the .msi file at location: C:\Windows\Downloaded Installations{FF12DD....}*.msi
After that I have created another product with updated version and install it over the older product. The latest ptoduct got installed successfully. After updating when I am trying to uninstall it, The updated product is using the older build .msi file. What I want here is it should use the latest build .msi file. Because I have made some changes in installScript of latest product which should get execute during un-installation.
In the updated product I am just updating product version number and not Product code. I don't want to modify the product code.
Thanks,
Sameer K
You need to read up on major upgrades and perhaps on some of the basics of Windows Installer. Essentially I think you should try to implement a major upgrade, it does involve changing the product code.
Don't be afraid to change the product code. It is the upgrade code that identify related versions of a product. The product code changes between versions. Essentially you author the upgrade table to detect other versions of your product, you update the version number of the MSI(first three digits count), and the package code should always change for every rebuild of the MSI. Finally you must keep the upgrade code the same across releases to make major updates easy to implement.
Installshield shields a lot of the complexity of this if you author the information found in the Upgrades view. Read the information provided here and you should be able to proceed.
Some further information on these important codes in an MSI. You must understand this even if you use Installshield's simplified GUI:
In every single rebuild of the MSI you MUST change the package code. This code should never have been exposed in the whole MSI design - it is used to uniquely identify a file. If you keep this guid the same across multiple files each file will be treated as the same file by definition - even if they are different files. This may cause the most mysterious problems you ever come across with MSI. Using the same package code several times is wrong in every case - unless you want to do hacking :-).
Package code: identifies unique MSI file
Product code: identifies product version
Upgrade code: identifies product family
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.
I have written a sequential workflow in SharePoint on our development environment. After testing, we decided to deploy this workflow as a feature on the staging environment. We did the following:
copied the strongly named assembly to the GAC using gacutil
copied feature.xml and workflow.xml to WebServerExtensions/12/templates/features/someFolder
installed feature (stsadm command)
activated feature (stsadm command)
All worked exactly as planned and the workflow behaved correctly. The problem was, we decided to change something in the code (a message was not very self explanatory), so on the development machine we updated the message as requested and rebuilt the project.
The problem is, we cannot seem to find a way to correctly get rid of the previous version of this workflow/feature.
To deploy the upgrade, we:
deactivated and uninstalled the feature (stsadm commands), removed also from GAC.
increased the version of the assembly
performed steps 1 to 4 from above.
When using the workflow we are still getting the first message, we cannot find a way to get the new message to be displayed.
What are we missing?
All the workflow logic "lives" inside the code assembly you are running. This means you can delete the old version of DLL (don't change assembly version numbers, use AssemblyFileVersion instead) from the GAC and replace it with the new version.
Be aware, though, that if you have changed the workflow in the designer, running instances of the old workflow version will "freeze" and never finish. Ask your users to finish their running WF-s before you upgrade the code.
It seems that the problem was in the Workflow.xml file.
Because I incremented the AssemblyFileVersion, and only replacing the dll in GAC did not work, I checked the two xml files: Feature and Workflow to see which one did not recognize the new dll (if the case). The workflow.xml file had a reference to the old version in it. I updated that, installed and activated the feature again, and it is working perfectly now.
Thanks for your support!