Working with an Informix 11.70 database in non-ANSI, unbuffered logging mode.
I am accessing this database through a GlassFish 3.1.2.2 server with a connection pool set up to use javax.sql.ConnectionPoolDataSource objects implemented by the com.informix.jdbcx.IfxConnectionPoolDataSource class.
All transactions are under the control of a JPA provider (Hibernate in this case), so there are no explicit BEGIN WORK, COMMIT WORK or ROLLBACK WORK statements that I have any control over.
In one particular deployment of this configuration, we are getting -255 errors, which signify either:
the database is in non-logging mode (this is not true in our case)
the database is in some kind of logging mode, but there was a COMMIT WORK issued by someone without a preceding BEGIN WORK statement
How do I go about troubleshooting this problem? What environmental factors would cause this error on one deployment and not on another?
The answer thankfully has nothing to do innately with Informix or Hibernate support for Informix. It has everything to do with obscure automatic data source creation in GlassFish that happens depending on how you deploy. (This may have something to do with the default properties that the Informix data source supplies to the GlassFish web console.)
Specifically, we had a case where our deployer attempted to deploy our application on GlassFish without first creating the required JDBC resource. GlassFish reported that some odd JDBC resources were missing: jdbc/foobar__pm and jdbc/foobar__nontx.
Our deployer, not figuring anything was wrong, created these resources by hand. (GlassFish apparently ordinarily creates these automatically when you deploy with its web console.)
As a result, our deployer had inadvertently specified a non-transactional data source for use by our application and that was the root cause here.
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)
I am using Visual Studio 2013 to manage a .sqlproj file containing our database schema. The schema has been deployed successfully dozens of times.
When attempting to publish to one specific target database, the "Creating publish preview" step appears to fail, but no error is given. The output from the preview includes some expected warnings:
The column {...} is being dropped, data loss could occur
If this deployment is executed, changes to {...} might introduce run-time errors in {...}
This deployment may encounter errors during execution because changes to {...} are blocked by {...}'s dependency in the target database
I have unchecked "Block incremental deployment if data loss might occur".
The Preview just stops, and no script is generated.
This happens when there exists a stored procedure (or view or constraint or other object) in the target database, that isn't included in your sqlproj, that references a table that would be altered by deploying your sqlproj. SSDT apparently can't determine whether the change is safe unless the referring thing is included in your sqlproj, and then it errs on the safe side by blocking the deployment.
Disabling the "Block incremental deployment if data loss might occur" option only relaxes the data-loss checks. There isn't a "Block incremental deployment if run-time errors might occur" option.
You have three options:
add whatever stored procedures, views, or whatever from the target database to your sqlproj
uncheck the "Verify Deployment" option in the ssdt publish options (this is dangerous unless you're aware of the other referring sprocs and know that they aren't going to break)
if you're certain that everything that should exist in the target database is contained in your sqlproj, you can enabled the "Drop objects in target but not in source" option
The issue may also be caused prepending a database object with the wrong schema. For instance a table being referenced within a stored procedure SQL statement and the table being prepended with an incorrect schema name.
Additionally, we had some permissions for a specific security group that once we removed the solution would build again. In order to troubleshoot the error perform a schema compare of the project code and the target database. Remove differences from the database until the publish functionality works. The last item that you removed from the database is your culprit.
The last warning pattern appears to be more than a warning:
This deployment may encounter errors during execution because changes
to {...} are blocked by {...}'s dependency in the target database
appears to have been the culprit behind stopping the rest of the preview and the generation of the script.
Interestingly, the schema change being introduced would not have broken the triggers referenced in the preview output.
removing schemabinding from the view allows the publish to succeed with only warnings
I run an ASP.Net MVC3 application and have followed this Windows Azure How-To on how to store my sessions in a co-located cache in Windows Azure.
I have installed the mentioned Nuget-package, and applied the necessary information to my web.config. The web role is setup to run 2 small instances, and use a 30% co-located cache.
When I deploy to Azure, my instances just recycle. Through a remote desktop connection to one of the instances, I have found these two events in the logs, that seem related:
The CacheStatusIndicator service terminated unexpectedly. It has done
this 1 time(s). The following corrective action will be taken in 1000
milliseconds: Restart the service.
The CacheService service terminated unexpectedly. It has done this 1
time(s). The following corrective action will be taken in 60000
milliseconds: Restart the service.
However, I cannot find much information on that.
Does anyone have a clue what I might be missing here?
I am very much sure that your role is missing some of the reference and because of that your see such message from CacheStatusIndicator. Have you verified that your role does have all the modules/references set to "copy local as true" so all of them are part of deployment package. Mainly it is a MVC3 app, you may need to manually set app MVC specific references property to copy local as true to resolved this problem.
Now I spent my shared amount of time dealing with this, and finally it seems to be working. Not sure exactly what part solved the problem, but I'll wrap up the changes I made, in case someone else have the same issue at some point.
While debugging this issue, I also updated my application from MVC3 to MVC4. Not sure if that has anything to do with solving this problem, but at least it is one of the changes I made.
I noticed that another exception was thrown by the the IntelliTrace service, so I disabled that in the deployment and re-deployed the application (my guess is that this problem is what actually caused the instances to cycle.
Response from Microsoft Support on this issue:
I was troubleshooting your deployment with the issue and I got a memory dump from the CacheService.exe
This was the exception being thrown
CLR exception type: System.TypeInitializationException
"The type initializer for 'Microsoft.ApplicationServer.Caching.AzureCommon.AzureUtility' threw
an exception." ModLoad: 000007feea010000 000007feea0fa000
D:\Windows\Microsoft.NET\Framework64\v4.0.30319\diasymreader.dll
* ERROR: Symbol file could not be found. Defaulted to export symbols for D:\windows\system32\KERNEL32.dll -
ntdll!ZwWaitForMultipleObjects+0xa: 00000000`76f5739a c3
ret
The exceptions on this namespace can happen if:
You set the Microsoft.WindowsAzure.Plugins.Caching.ConfigStoreConnectionString setting on ServiceConfiguration to use the local storage emulator
On the web.config you have the identifier value of the <dataCacheClients> section not set to the correct role name
In some rare cases if you have the SDK 1.6 and 1.7 installed together this can cause some mixed up DLLs when project is being built.
I'm building a web application which soon I'll be promoting to production. This application has a login screen, as you know I used the integrated DB for developing. Now I want to move this database to a full SQL Server 2005. I'm using the aspnet_regsql.exe to create my membership tables and stored procedures in the SQL Server 2005 but I'm getting an error:
An error occurred during the execution of the SQL file 'InstallMembership.sql'. The SQL error number is 207 and the SqlException message is: Invalid column name 'FailedPasswordAnswerAttemptWindowStart'.
I google this for half of the day already and I can't seem to fine what's wrong, does anybody have ANY ideas on what am I doing wrong here? Any help will be really appreciate it.
The easiest way to deploy a brand new database to a remote server is to just publish the database from within Visual Studio. Once you do that you have the scheme and data all in one script. You then access your server either via a local SQL manager connection or a remote manager and run the script on your remote database.
The site 4GuysFromRolla has a nice little walk through with graphics which describe how to accomplish the publishing of your local database to your hosted one.
Good luck, and hope this helps you out some.
Go through the *.sql script file and see where that column reference is. Then you'll be able to see what exactly the script is doing to cause this error. My guess would be that it is getting caught up on referential integrity. If it is trying to create a foreign key constraint that that table/column does not exist then you'll see that error.
But back to the original question at hand. You don't need to recreate your whole database. That script file is to lay down the Membership for an empty database. If you have a working dev database you can just back it up and restore it to a production instance. No need to rebuild the membership database objects.
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.