i am trying to create a workbook from the asp.net solution and save it at a specified folder but whilt creating the odject of workbook am getting this error
Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80080005.
have tried setting permissions through dcomcnfg i.e. Interactive,launching and this user
I have deployed new build on IIS server... whenever i deploy new build i get this error
If your server is 64-bit, that might be what's causing this issue. Take a look at this question on SO:
Issue with Microsoft.Office.Interop.Excel.dll while converting application to 64 bit
Related
I know a similar question already asked here but since given answer don't help me and my problem is kinda different I'm asking a new question.
I create data sources through admin panel -> Configure -> Datasources and it works fine. But if I restart server all created Datasources gonna missing from datasources list.
When I run ESB server I can see through logs that those datasources could not be loaded properly since ESB server is unable to decrypt sensitive data which it encrypted earlier:
DataSourceRepository Error in updating data source [remove:false] at path '/repository/components/org.wso2.carbon.ndatasource/myDatasource
Error in updating data source 'myDatasource' from registry
[remove:false]: Error in secure load of data source
meta info: An error occurred while decrypting data
Although myDatasource is missing from datasources list I can still see it in registry through admin panel -> Registry -> /_system/config/repository/components/org.wso2.carbon.ndatasource/myDatasource
I have the same issue. This seems to be some error introduced in 6.4.0.
6.3.0 does not exhibit this behaviour.
As a workaround, if you define the datasources in /conf/datasources/master-datasources.xml then the datasources load correctly at server startup. However this is not ideal solution as they cannot then be edited through the web console.
Alternatively you can download the registry entry , edit the password element to remove 'Encrypted=true' and change the password to be unencrypted. Then upload the edited file as a new registry entry alongside the old.
Both these methods are not feasible for production though as they leave the passwords unencrypted.
Out of interest are you running this on Windows? I discovered also on EI 6.4.0 that the Ciphertool utility will not run due to a malformed path. I suspect this might be related, but I cannot find where the malformed path is coming from it seems to be repeating the {carbon.home} element within the path :
C:\Program Files\WSO2\Enterprise Integrator\6.4.0\bin>ciphertool
Using CARBON_HOME: C:\Program Files\WSO2\Enterprise Integrator\6.4.0
Using JAVA_HOME: C:\WSO2\Enterprise Integrator\6.3.0\jdk\jdk1.8.0_192
Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <:> at index 51: C:\Program Files\WSO2\Enterprise Integrator\6.4.0\C:\Program Files\WSO2\Enterprise Integrator\6.4.0\/repository/resources/security/wso2carbon.jks
at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
at java.nio.file.Paths.get(Paths.java:84)
at org.wso2.ciphertool.utils.Utils.getConfigFilePath(Utils.java:98)
at org.wso2.ciphertool.utils.Utils.setSystemProperties(Utils.java:289)
at org.wso2.ciphertool.CipherTool.initialize(CipherTool.java:93)
at org.wso2.ciphertool.CipherTool.main(CipherTool.java:52)
BizTalk 2013, production server, on windows 2008 R2 64 bit all host instances failed to start,
event log:
Error code 0x80131604, Error description: Exception has been thrown by the target of an invocation.
Googled a bit, there are threads saying it could be BizTalk configuration file issue, I copied one file from a non production server which works but still facing the same issue.
Any idea where to look?
This is - indeed - likely an issue with the configuration file. Most likely, the configuration file does not contain valid XML.
Try making a copy of the file and renaming that copy with an .xml extension. Than open it up in a browser or any program that includes an XML parser to see if the XML in the file is valid.
If you are unsure, try putting the XML in your question here (sanitize any senstive data before posting) and we'll take a look.
Any other errors you can see in the event log(s)?
I'm using Code First concept in Entity Framework and I'm constantly getting the following exception while starting application:
Cannot attach the file 'C:\Users\Admin\Documents\Visual Studio 2012\
Projects\Pro\Pro.Web\App_Data\Pro.mdf' as database 'Pro'.
I've put this in Global.asax.cs but also without success:
Database.SetInitializer(new DropCreateDatabaseIfModelChanges<ProWebContext>());
var ctx = new ProWebContext();
ctx.Database.Initialize(true);
I've checked under App_Data directory and there no database created. Also, under Server Explorer there is nothing under Data Connections. Everything was working fine yesterday and today not working at all. I've tried to connect to LocalDB with SQL Server Management studio but it says it cannot connect to local database. Any ideas what could be a problem?
Thanks!
I found the solution. With newest SQL Server Management studio there is no problem in connecting to the local database. Connection needs to be established like this:
After logging in we can still see old database present even if there is nothing under App_Data directory and under Data Connections in Server Explorer in Visual Studio. When we delete that database from SQL Server Management studio and start application again there will be no more errors while attaching database.
I was facing the same error when I saw this but I couldn't delete the database using SQL Server Management Studio so I remembered IDatabaseInitializer.
Setting a database initializer for my Code First context solved the issue. In my case adding an initializer to always drop the DB worked (I added the code in the static constructor of my context, most people add it in Global.asax):
static SomeDbContext()
{
System.Data.Entity.Database.SetInitializer(new DropCreateDatabaseAlways<SomeDbContext>());
}
There are other initializers of course.
I just got into the same problem, and yet the answers above helped, the solution was different.
In my case, I was reusing a project that has already created it´s database. And since the name in the config was the same, it was throwing the exception, missleading the real solution.
It worth checking the database is not created and is different than the ones you used before. Change the name and go ahead.
I deleted the mdf file manually so the code will recreate it again, and had the same problem. I solved it by running update-database command in the package manager console.
I have a ASP.Net program written in C# that uses a database stored in the AppData directory, the program works perfectly on my development (Win7\SQL 2008R2) when I deploy to a Win2008R2\SQl 2008 R2 server the program is unable to connect to the database. I'm using the connection string below. Several sites suggest I set the Application Pool to use 'Network Service' as this has Modify permission to the AppData directory, I have done this but it still won't work, another site suggested I Application Pool to "Load User Profile = True" but still no joy.
I'm pulling my hair out with what else to try, can anyone help?
data source=.\SQLEXPRESS;Integrated
Security=SSPI;AttachDBFilename=|DataDirectory|\DB.mdf;User
Instance=true
I get "Object reference not set to an instance of an object." in my app and "An attempt to attach an auto-named database for file C:\inetpub\wwwroot\ADPhonebook\App_Data\DB.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share." in the Application Event Log
I really appreciate any advice, thanks.
Steven
As Martin points out in the comments, it would be interesting if you posted the exact error message (and maybe the full exception detail) you are getting.
But problems like this have mostly to do with rights at the OS level.
So make sure that the user (identity) of the Application Pool has full access (ntfs) rights to the .mdf file, and try again.
Edit (after you posted the exact message):
Ok, I guess this means that on the server you're deploying to, there is already a database called DB on that Sql Server instance. So you will have to remove or rename that one in order to be able to attach a database with that name.
I think the user rights problem is also still possible though.
Since the answers did not really cover the problem, I posted this on ASP.Net and completly rephrased it. I will post the edited question here:
I have been using the attachDB connection string and I usually deploy to IIS. The site works fine, however, I made some changes to the database and the newest version would not copy as it said file in use.
I opened up SQL management studio and saw that it was mounted so I did a dettach.
I was then able to copy the new version without problem, however, when I next run the site, I get:
Unable to open the physical file "C:\inetpub\wwwroot\vs\App_Data\aspnetdb.mdf". Operating system error 5: "5(failed to retrieve text for this error. Reason: 15105)".
An attempt to attach an auto-named database for file C:\inetpub\wwwroot\vs\App_Data\aspnetdb.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
And, if I try to access .Net users or the other few options within IIS Manager, I get the following error:
.NET Users
There was an error while performing this operation.
Details:
A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)
OK
I have tried recycling the application pool, restarting the SQL instance and even restarting the computer.
Nothing helps and I cannot figure out what is wrong... Where does it remember where previous databases are connected and why doesn't it automatically reattach the database?... Someone said that they auto detach after 2 1/2 hours, however I waited 5 hours when a database wasn't in use and SQL Manager showed it was still attached.
When I manually reattach the database, everything works fine.
When you ask a database to be attached on-the-fly to a SQL Express instance using the AttachDBFileName connections string the application will not connect to the SQL Expres sinstance at all, but instead it will connect to a child instance, which is an new instance created specificaly for the user requesting the attach operation. See SQL Server 2005 Express Edition User Instances. This child instance will attach the database and will continue to run for up two one hour, after which it will shut itself down.
When you try to connect from 'enterprise manager' you will not be able to connect to the child instance (is realy complicated to connect explicitly to one, so you cannot accidentaly do it), you are connecting to the parent instance and messing with the database.
To summarize, either stick with the RANU model and use AttachDBFileName, or use a normal database operations mode and manage the database from the SSMS. Don't mix the two.
Are you certain there isn't already a database with the same name attached to the SQL Express instance you are pointing your site at?
Also, does the identity the site is running under when it attempts to attach the database have admin rights in SQL Express? If not, this command won't work (I'm not sure what error it gives in that situation, but "Access Denied" would sound reasonable).
The page "SQL Server 2005 Express Edition User Instances" seems to give a good overview of the issues and workarounds.
Edit to add
Could this be the issue:
An error will be generated if a log file exists in the same directory as the data file and the 'database' keyword is used when attaching the primary data file. In this case, remove the log file. Once the database is attached, a new log file will be automatically generated based on the physical path.
Taken from the documentation for SqlConnectionStringBuilder.AttachDBFileName Property
You'll need to delete the log file before you can re-attach the database through this method.