Mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "RsiDotNetDll", "x86".
I’m facing a problem while implementing an application on azure I have a dll that is of x86 architecture and is referred
in my application. It is the core or base of my application. When I run that application locally it runs fine but when I try to publish that application to Azure from Visual studio 13. It shows an error that the dll and its dependencies are missing.
And it giving an error like :
Warning 1 There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "RsiDotNetDll",
"x86". This mismatch may cause runtime failures
Hi Suresh,
Thanks for your posting!
I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Best Regards,
Will
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.
Similar Messages
-
I am seeing the following warning is a SSIS C# script and receive a SSIS abort when I attempt to run the package.
The SSIS log indicates the package is failing at about this same step in the process.
I have also included the file SSQLDUMPER_ERRORLOG.log that SSIS generates when it aborts below.
My SSIS package has been set to 64-bit and I only have 64-bit SQL Server 2012 installed on the box.
I migrated the package using the latest version of Data Tools that came out around mid July 2014.
I edited all connection manager strings to point to 64-bit SQL Server and I run using the following command
I edited the run string to point to the new 64 bit DTExec and attempted to run.
C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe" /Rep V /F PkgMigration.dtsx .........................
A significant amount of work does occur as reflected by the log steps prior to DTEXEC aborting but the log does just quit in mid sentence so not sure if it might have actually got a bit further.
Any help on understanding what is happening here would be most appreciated.
Warning 1 There was a mismatch between the processor
architecture of the project being built "MSIL" and the processor architecture of the reference "Microsoft.SqlServer.DTSRuntimeWrap, Version=11.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91", "x86". This mismatch may
cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a
processor architecture that matches the targeted processor architecture of your project. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
1605 5 sc_5756696d96034309a51afe69fed2eb44
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 1: 6100
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 2: 0
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 3: 0:0
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 4: 00A8B770
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parsed parameters:
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 6100
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x00A8B770
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x00000000
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files (x86)\Microsoft SQL Server\110\Shared\ErrorDumps\SQLDmpr0007.mdmp
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll'
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE'
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '2011.110:5058.0'
(1CBC:1808) 08/14/14 10:36:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '11.0:5058.0'
(1CBC:1808) 08/14/14 10:36:47, ACTION, DTExec.exe, Watson Invoke: No
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 1: 10124
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 2: 0
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 3: 0:0
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 4: 0012B770
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parsed parameters:
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 10124
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x0012B770
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x00000000
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files (x86)\Microsoft SQL Server\110\Shared\ErrorDumps\SQLDmpr0008.mdmp
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll'
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE'
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '2011.110:5058.0'
(2724:2488) 08/14/14 10:43:09, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '11.0:5058.0'
(2724:2488) 08/14/14 10:43:09, ACTION, DTExec.exe, Watson Invoke: No
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 1: 8716
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 2: 0
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 3: 0:0
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 4: 0072B770
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parsed parameters:
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 8716
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x0072B770
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x00000000
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files (x86)\Microsoft SQL Server\110\Shared\ErrorDumps\SQLDmpr0009.mdmp
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll'
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE'
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '2011.110:5058.0'
(2240:89C) 08/14/14 10:51:56, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '11.0:5058.0'
(2240:89C) 08/14/14 10:51:56, ACTION, DTExec.exe, Watson Invoke: No
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 1: 8856
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 2: 0
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 3: 0:0
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 4: 009AB770
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parsed parameters:
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 8856
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x009AB770
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x00000000
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files (x86)\Microsoft SQL Server\110\Shared\ErrorDumps\SQLDmpr0010.mdmp
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll'
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE'
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '2011.110:5058.0'
(7B8:1E68) 08/14/14 11:01:36, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '11.0:5058.0'
(7B8:1E68) 08/14/14 11:01:36, ACTION, DTExec.exe, Watson Invoke: No
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 1: 1292
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 2: 0
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 3: 0:0
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 4: 00BFB770
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parsed parameters:
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 1292
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x00BFB770
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x00000000
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files (x86)\Microsoft SQL Server\110\Shared\ErrorDumps\SQLDmpr0011.mdmp
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll'
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE'
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '2011.110:5058.0'
(229C:1CD8) 08/14/14 11:45:45, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '11.0:5058.0'
(229C:1CD8) 08/14/14 11:45:45, ACTION, DTExec.exe, Watson Invoke: No
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 1: 4220
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 2: 0
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 3: 0:0
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 4: 0019B770
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parsed parameters:
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 4220
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x0019B770
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x00000000
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files (x86)\Microsoft SQL Server\110\Shared\ErrorDumps\SQLDmpr0012.mdmp
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll'
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE'
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '2011.110:5058.0'
(2520:2624) 08/14/14 12:05:47, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files (x86)\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '11.0:5058.0'
(2520:2624) 08/14/14 12:05:47, ACTION, DTExec.exe, Watson Invoke: No
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 1: 8408
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 2: 0
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 3: 0:0
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parameter 4: 00000000003ECC18
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Parsed parameters:
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 8408
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x00000000003ECC18
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x0000000000000000
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x0000000000000000
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
(1B5C:20C0) 08/18/14 14:21:48, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 15 not used
(1B5C:20C0) 08/18/14 14:21:50, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
(1B5C:20C0) 08/18/14 14:21:50, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files\Microsoft SQL Server\110\Shared\ErrorDumps\SQLDmpr0001.mdmp
(1B5C:20C0) 08/18/14 14:21:50, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'dbghelp.dll' : 'C:\Program Files\Microsoft SQL Server\110\Shared\dbghelp.dll'
(1B5C:20C0) 08/18/14 14:21:50, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(1B5C:20C0) 08/18/14 14:21:50, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files\Microsoft SQL Server\110\Shared\dbghelp.dll' : '6.12:2.633'
(1B5C:20C0) 08/18/14 14:21:50, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Location of module 'sqldumper.exe' : 'C:\Program Files\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE'
(1B5C:20C0) 08/18/14 14:21:50, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, File version of module 'C:\Program Files\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '2011.110:5058.0'
(1B5C:20C0) 08/18/14 14:21:50, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Product version of module 'C:\Program Files\Microsoft SQL Server\110\Shared\SQLDUMPER.EXE' : '11.0:5058.0'
(1B5C:20C0) 08/18/14 14:21:50, ACTION, DTExec.exe, Watson Invoke: NoHi GaryAMiller,
It seesm this is a know ssue. Please take a look at the following simialr issue at Microsoft Connect site:
MSB3270: Mismatch between the processor architecture:
https://connect.microsoft.com/VisualStudio/feedback/details/804933/msb3270-mismatch-between-the-processor-architecture-fakes-framework
If this issue still persists, I would suggest
opening a case with Microsoft Customer Support Services (CSS)(http://support.microsoft.com), so that a dedicated Support Professional can assist you in a more efficient manner.
If you have any feedback on our support, please click
here.
Elvis Long
TechNet Community Support -
Microsoft Fakes MSB3270: There was a mismatch between the processor architecture
Hi,
I´m using Microsoft fakes in my test project and it shows this annoying message:
warning MSB3270: There was a mismatch between the processor architecture of
the project being built "MSIL" and the processor architecture of the reference
"ThirdPartyDll, Version=xxx, Culture=neutral, processorArchitectu
re=x86", "x86". This mismatch may cause runtime failures. Please consider chang
ing the targeted processor architecture of your project through the Configurati
on Manager so as to align the processor architectures between your project and
references, or take a dependency on references with a processor architecture th
at matches the targeted processor architecture of your project.
The fake has been created from a Project which references Microsoft.VisualStudio.Coverage.Analysis which has been compiled in x64 (I´ve had problems too with this assembly becuase I´m using it in a custom activity for a build definition, you can see
this post regarding that
http://social.msdn.microsoft.com/Forums/en-US/tfsprocess/thread/d4896ad3-aba1-4c36-8570-dcc55c41df95/).
I can use the following tag to hide the warnings during the project compilation but it doesn´t work for fakes:
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
https://connect.microsoft.com/VisualStudio/feedback/details/728995/new-vs2010-project-compiler-warning-since-installing-dotnet4-5-vs2011-beta
So, any ideas about how to solve this?
RegardsHi Chirstian,
Although the link is quite old I´m working with the update 1 of VS2012.
You can reproduce the warning very easily.
1. - Create a new class library project.
2. - Add a reference to Microsoft.VisualStudio.Coverage.Analysis.dll (not the one located in Program Files x86\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies) from your Build Server (located in your build machine -> Program Files\Microsoft
Team Foundation Server 11.0\Application Tier\TFSJobAgent\plugins. I ´ve put this assembly in my Versión Control path to custom assemblies).
3. - Compile the project. You´ll get the warning MSB3270 for the class library. You can solve this warning creating the following property group for the library project:
<propertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
None
</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</propertyGroup>
With this tag, the warning will disappear.
4. - Create a new Test Project. Add a reference to the same Coverage assembly as you did previously and you´ll get the same warning. Put the tag to solve it.
5. - In the test Project, add a reference to the class library project created previously. After that, add fakes assembly for this assembly. Right now, if you compile the Project you should get the warning.
Microsoft.QualityTools.Testing.Fakes.targets (62,5) : Warning MSB3270: There was a mismatch between the processor architecture...
I´m afraid I can´t send you a sample project. You can ask me whatever you want if you need help to reproduce it though.
Regards. -
I have a SSRS installation, I have deployed my connections to, but they fail with title message. The drivers and ODBC on the box are setup and work fine with 32 bit ODBC conn manager.
When I run or configure my connections on the site, via the browser, I get errors connecting.
I tried to find which app pool http://server/ReportServer application used, but I am not finding that, so my first ?
How do I find in IIS what app pool SSRS application is using?
I have 2008 server, running SQL 2012 V.S. 2010 and I think I need to enable my app pool to use 32 bit, but cannot figure out which one it uses? I see default set to 32 bit = true, which I thought would be it.
Can I set my SSRS project to use x86, platform? Like I did with SSIS?
If so, how? SSRS and SQL 2012 somewhat new for me. Thanks
Developer MS Reporting ServicesHi DCady,
To manage a data source that connects to a 32-bit driver under 64-bit platform, we use C:\Windows\SysWOW64\odbcad32.exe. To manage a data source that connects to a 64-bit driver, we use C:\Windows\System32\odbcad32.exe.
Generally, if we use the 64-bit odbcad32.exe (C:\Windows\System32\odbcad32.exe) to configure or remove a DSN that connects to a 32-bit driver, for example, Driver do Microsoft Access (*.mdb), we will receive the following error message:
The specified DSN contains an architecture mismatch between the Driver and Application
To resolve this error, we need to use the 32-bit odbcad32.exe (C:\Windows\SysWOW64\odbacad32.exe) to configure or remove the DSN.
Besides, please make sure there are no DSN using the same name in both 64-bit and 32-bit ODBC Data Source Administrator.
Reference:
Managing Data Sources
Regards,
Mike Yin
If you have any feedback on our support, please click
here
Mike Yin
TechNet Community Support -
We have a web role where we have hosted a WCF service.
We are facing the below exception intermittently on consuming the service.
Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties. This
can occur if the service is configured for security and the client is not using security.
This is intermittent. Few calls fail , and the subsequent calls succeed without making any changes.
Please help in overcoming this abnormal behavior.
Thanks in advance !!
Best Regards ,
EswarHi Eswar,
As the error message mentioned, it may be a mismatch between the configuration on the client and the server.Try putting all your configuration in a binding configuration and then use the same binding configuration on the server and client. Since this issue
is more related with WCF, I suggest you move to WCF forum, it is appropriate and more experts will assist you.
Best Regards,
Jambor
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey. -
Mismatch between the MD04 and VL10 tcodes.
Hello Gurus,
There is a Mismatch between the MD04 and VL10 tcodes. We can see an entry in the VL10 transaction which we couldn't find in the MD04. Please note that there is no dschedule line for that date in the LU aggrement. Kindly advice.can be an error in in the delivery index.
run SDRQCR21 report?
And see if the record appears in MD04 or vanishes from VL10 -
Mismatch between the patch version
Version 2.18, next step, next issue. Got through the 'Do Setup' step on "9-Apply DBA CUP and related patches" with a bug workaround that was provided. Now went to the next step of 'Do Execute' and it is failing with the message below. I've done some inital searching and haven't found an answer. There was one note on MOS about a very similar issue but it was resolved in 2.16. Posting here whild I spend more time researching and trying to figure out the reason. I also reviewed my notes from when I did this upgrade manually and these mereged patches were not applied in preinstall mode as the message is saying has to be done. Any help would be appreicated. Thanks!.
patchit12.sh - is exiting with no actions. ie. Patch patchfile_ad17089s not applied.
There is a mismatch between the patch version specified and the release
version obtained from your Applications environment. In order to apply
Release 12 patches to previous Applications versions, the patch must be
applied in preinstall mode.This can be done by passing the appropriate
value to the preinstall parameter of eof_patch12.sh.
INFO: Not starting patch alert monitor, to start: Login Engineer, User Admin, Update Profile
Version in scripts/COMMON
# $Header: patchit12.sh 1.32 2009/09/15 16:00:00 vpickard $
Edited by: user649511 on Mar 2, 2011 2:24 PMYou can change following in patchit12.sh under ./eof/scripts/COMMON. Please change it back before executing any other steps.
From
Check_Release()
#Check if the releasenr is OK
if [ "${preinstall}" = "y" ];then
RELEASE=12
echo
echo "patchit12.sh is installing: $patch in preinstall=y mode."
else
REL=`Get_Release`
RELEASE=`echo $REL | awk '{print substr($1,1,2)}'`
echo
echo "Found release REL=$REL from fnd_product_groups."
fi
to
Check_Release()
#Check if the releasenr is OK
if [ "${preinstall}" = "y" ];then
RELEASE=12
echo
echo "patchit12.sh is installing: $patch in preinstall=y mode."
else
REL=`Get_Release`
#RELEASE=`echo $REL | awk '{print substr($1,1,2)}'`
RELEASE=12
echo
echo "Found release REL=$REL from fnd_product_groups."
fi -
There is a compatibility range mismatch between the Web server and database
HI,
Taken backup form production environment through TSM backup utility and restore same db on UAT environment by TSM Utility, after restore got below issue, past i had done many time but working fine this time
it’s not working. Production environment have SP2010 and sql server 2008 ,UAT have same thing also.
Server Error in '/' Application.
There is a
compatibility range mismatch between the Web server and database "Portal_Contain", and connections to the data have been blocked to due to this incompatibility. This can
happen when a content database has not been upgraded to be within the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the database must be upgraded to the same version and
build level to return to compatibility range.
Description: An unhandled exception occurred during the execution of the current
web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Microsoft.SharePoint.Upgrade.SPUpgradeCompatibilityException:
There is a compatibility range mismatch between the Web server and database "Portal_Contain", and connections to the data have been blocked to due to this incompatibility. This can happen when a content database has not been upgraded to be within
the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the database must be upgraded to the same version and build level to return to compatibility range.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack
trace below.
Stack Trace:
[SPUpgradeCompatibilityException: There is a compatibility range mismatch between the Web server and database "Portal_Contain", and connections to the data have been
blocked to due to this incompatibility. This can happen when a content database has not been upgraded to be within the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the
database must be upgraded to the same version and build level to return to compatibility range.]
Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.ValidateBackwardsCompatibility() +542
Microsoft.SharePoint.SPSite.PreinitializeServer(SPRequest request) +63
Microsoft.SharePoint.SPWeb.InitializeSPRequest() +258
Microsoft.SharePoint.WebControls.SPControl.EnsureSPWebRequest(SPWeb web) +365
Microsoft.SharePoint.WebControls.SPControl.SPWebEnsureSPControl(HttpContext context) +520
Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.GetContextWeb(HttpContext context) +27
Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.PostResolveRequestCacheHandler(Object oSender, EventArgs ea) +918
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +171
Hasan Jamal Siddiqui(MCTS,MCPD,ITIL@V3),Sharepoint and EPM Consultant,TCS
|
| TwitterHi Bhavik,
UAT Portal_Contain DB version given below:
Version ID
Version
id
00000000-0000-0000-0000-000000000000
12.0.0.4518
1
00000000-0000-0000-0000-000000000000
12.0.0.6219
3
00000000-0000-0000-0000-000000000000
12.0.0.6327
4
00000000-0000-0000-0000-000000000000
12.0.0.6421
5
00000000-0000-0000-0000-000000000000
12.0.0.6510
6
00000000-0000-0000-0000-000000000000
12.0.0.6514
7
00000000-0000-0000-0000-000000000000
14.0.6123.5006
9
1A707EF5-45B2-4235-9327-021E5F9B8BB0
4.1.6.0
8
6333368D-85F0-4EF5-8241-5252B12B2E50
4.1.18.0
2
Production Version given below:
00000000-0000-0000-0000-000000000000
12.0.0.4518
00000000-0000-0000-0000-000000000000
12.0.0.6219
00000000-0000-0000-0000-000000000000
12.0.0.6327
00000000-0000-0000-0000-000000000000
12.0.0.6421
00000000-0000-0000-0000-000000000000
12.0.0.6510
00000000-0000-0000-0000-000000000000
12.0.0.6514
00000000-0000-0000-0000-000000000000
14.0.6123.5006
1A707EF5-45B2-4235-9327-021E5F9B8BB0
4.1.6.0
6333368D-85F0-4EF5-8241-5252B12B2E50
4.1.18.0
I have matched both are the exact same.
Run the below command on App server:
Upgrade-SPContentDatabase
cmdlet Upgrade-SPContentDatabase at command pipeline position 1
Supply values for the following parameters:
Identity: Portal_Contain
Confirm
Are you sure you want to perform this action?
Performing operation "Upgrade-SPContentDatabase" on Target "Portal_Contain".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):y
WARNING: Database [SPContentDatabase Name=Portal_Contain] cannot be upgraded.
Kindly suggest
Hasan Jamal Siddiqui(MCTS,MCPD,ITIL@V3),Sharepoint and EPM Consultant,TCS
|
| Twitter -
Mismatch between the Content Database size and the total of each site collection' storage used.
Hi All,
Environment: SharePoint 2010 with SP2.
Issue: One of the Content databases size in our farm shows 200 GB as used. There are 25 site collections in the DB and we counted
the total storage used of all site collections in that Content DB and is not more than 40 GB. (used "enumsites" command and counted the each sitecollections storage used).
What actions/troubleshooting were done?
Ran one script which will find the actual size of site collection and how much space used in the disk. But didn’t find major difference in the report.
Checked “Deleted from end user recycle bin “in all the site collections and no major storage is noticed.
Planning to Detach the problematic Content DB and attach ,will check whether any major effect is there
Why the Content DB shows 200 GB as used when the total storage used of all site collections is just 40 GB.
Appreciate suggestions from any one.
Best Regards,
Pavan Kumar Sapara.
s p kumarHi,
Thanks for your reply.
As there is only 20 MB of unallocated space for the above said DB, SQL DB team informed that they cannot perform the DB shrink at this moment.
So we are thinking to Offload all the site collections to other new DB and then will Drop the problematic database. In this way we can overcome the
issue.
Answer for your queries.
Are the mismatched sizes causing an issue? Are you short on diskspace for DB storage or SQL backups?
No, there is no issue with the mismatched sizes. We are not on short on disk space. We just worried why it occupies that much size(200 GB) when
the total storage used of all site collections in that DB is 40 GB.
Best Regards,
Pavan Kumar Sapara.
s p kumar -
Mismatch between the bean code and generated code
Hello all,
I am running WL7.0Sp2 on Winnt4.0Sp6 connecting to Oracle 8.17. I have been running
my app on this server for a while (all my beans deployed ok, WL started up fine,
no problems). From last week, all of a sudden, I am getting the error attached
when I am trying to deploy just one bean (?). The weird thing is it deploys fine
in every other env. except fine (so I am guessing something must have gone awry
in my class path) but I cant figure this out?
Any ideas? suggestions?
Thanks
Sury
[deploy_error.txt]To be sure, I'd recompile the jar and also make sure that
none of the Bean related interfaces are reachable from the
server's CLASSPATH. -
Output mismatch between BEx query output and WebI Report output
Hi All,
I have a BEx query in which there are only characteristics placed in rows.
There are combinations of the values of the characteristics giving different records in the query output.
Date is one of the characterisctics in the query output.
There is an output mismatch between the query output and the WebI report output in the following case:
When there are 'Not Assigned' or '#' or blank values, there are additional entries(rows) in the WebI report, giving repeating or wrong entries in the Date field. This is incorrect data.
Is this because of the 'Not Assigned' or '#' or blank values of the Characteristics or is there any other reason?
How do I fix this?
Please helo me with this.
Thanks and Regards,
Srilakshmi BHi Rajesh,
I need to verify the WebI report output for records with # and 'Not assigned' values for the cHracteristics in the report.
So I cannot check the WebI report by hiding the # or Not assigned values.
The problem is that in the Query output the records are like these shown below:
Char1 CHar2 CHar3 Date field
A B C Date1
#(Not assgined) #(Not assgined) #(Not assgined) No value
Where as the WebI report output is as below:
Char1 CHar2 CHar3 Date field
A B C Date1
#(Not assgined) #(Not assgined) #(Not assgined) Date1
As shown here, there are wrong/repeating entries for the Date field in the WebI report output.
Please check this and let me know what could be the issue and how do I fix it.
Thanks and Regards,
Srilakshmi B -
IDoc structure mismatch between SAP R/3 and PI
Hi,
There is an interface in PI which receives IDoc from SAP R/3 system. I have been facing an issue of IDoc structure mismatch (in terms of data present in it) between SAP R/3 and when PI receives the IDoc.
To be more precise,
In SAP R/3 system, the value ABC is present in the field DOCNUM in the IDoc.
But when the PI receives the same IDoc from SAP R/3 (as seen in Integration Engine), the value ABC is present in a different field and the DOCNUM field is empty.
<DOCNUM></DOCNUM>
<ARCKEY>ABC</ARCKEY>
The first step towards resolution was to delete and reimport the IDoc metadata from SAP R/3 in PI system using IDX2, which did not help in this case.
Could anyone please help in resolving the field mismatch between the IDoc triggered from SAP R/3 and the IDoc received by PI.
Regards,
PrajeetHi Prajeet,
it's long ago but your question has not been finally solved, so let me try to give you an answer. We are facing the same problem after patching our PI.
I think the reason for the different behaviour is related to SAP note 1233908, where SAP has changed the IDoc adapter.
https://service.sap.com/sap/support/notes/1233908
Regards,
Lars -
Mismatch between preview in wwi template and cbgl_mp01 preview
Hello ,
I am getting a huge mismatch between the preview for label in wwi and the preview at the time of label printing through t-code cbgl_mp01 .Can anyone suggest me the troubleshooting techniques please .
Regards,
M DHello C B ,
I designed 4X6 inch label template in wwi . My label size is also 4X6.also my label stock size is also 4X6 . I have taken 4 as width and 6 as height in wwi and GLM config . I put 4 pictogram in my template . I am getting the 1st one full and the second one from top to right as half and both the below pictograms though it shows in preview but while doing print out it is missing . Has anyone come across this situation yet ? I tried a lot but the lower two pictograms are not coming into the printer paper .
M D -
How to know if your mac is using the latest Haswell architecture processor or not? and how to know the difference between the new imac and the 2012/13 imac?
Sorry to reopen an old post, but I've just purchased a 2nd hand late-2013 iMac (or so thats what the seller said).
I'm always sceptical though, and just wanted to know if there is a way to check if my iMac is indeed the late-2013 model that included Haswell?
I've attached screenshots of the About This Mac section hoping it may help shed some light.
Thank you in advance for your help!
PS - I can't compare to the iMac specs link you posted above because its now showing the late-2014 models.
<Image Edited by Host to Remove Serial Number> -
How to identify the data mismatch between inventory cube and tables?
Hi experts,
i have a scenario like how to identify the data mismatch between 0IC_C03 and tables,and what are the steps to follow for avoiding the data mismatchHi
U can use data reconcilation method to check the consistency of data between the r/3 and bw. Plz check the below link
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/a0931642-1805-2e10-01ad-a4fbec8461da?QuickLink=index&overridelayout=true
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d08ce5cd-3db7-2c10-ddaf-b13353ad3489
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/7a5ee147-0501-0010-0a9d-f7abcba36b14?QuickLink=index&overridelayout=true
Thanx & Regards,
RaviChandra
Maybe you are looking for
-
Procedure of scheduling agreement with jit
Can any one explain the step by step by procedure of creation of scheduling agreement with jit(just in time) Vasu,K
-
Bapi for subcontracting purchase order
Hi, is there a BAPI allowing to create a subcontracting purchase order? Best regards.
-
HT204003 How can I get .pkpass files on my Mac to Passbook on the iPhone?
I've used Passbook sucessfully on my iPhone before (boarding passes). However, I just downloaded an .pkpass file from a web site to my Mac, and I can't get the pass to the iPhone. If I double-click on the file, something called Pass Viewer asks if I
-
XML - Adobe ActionScript 3 (AS3 ) API Reference
This question was posted in response to the following article: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/XML.html
-
I was trying to create a list manager with the values from this sql stmt select vb.vcbauto, v.vendor_name, c.contact_name, b.bid_number, b.contract_description from purch_vendor_bid vb, purch_vendor v, purch_contact c, purch_bid b, purch_vendor_conta