If I do sqllocaldb i from the command line I see a list of instances as I expect, but there is one in there which I find I cannot delete nor connect to. Let's call it "troublesome".
If I try and access it using the SqlLocalDb API:
GetInstances() returns the same list of instances that sqllocaldb i does, including the troublesome one, yet GetInstance("troublesome") throws an exception "The SQL LocalDB instance 'troublesome' does not exist".
I can create a second instance with the same name as the troublesome one, no problems. sqllocaldb c troublesome works, just fine (I end up with two "troublesome" in the list), and I can delete it too. But the original one is still there.
Any clues?
This was caused by a stray localdb registration from a previous (deleted) user account.
If you look in the registry at the following key: HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\UserInstances you can see all the instances.
The troublesome instance was there with a DataDirectory path set to an invalid location.
Related
I am running into a very strange issue with Spring Boot and Spring Data: after I manually close a connection, the formerly working application seems to "forget" which schema it's using and complains about missing relations.
Here's the code snippet in question:
try (Connection connection = this.dataSource.getConnection()) {
ScriptUtils.executeSqlScript(connection, new ClassPathResource("/script.sql"));
}
This code works fine, but after it executes, the application immediately starts throwing errors like the following:
org.postgresql.util.PSQLException: ERROR: relation "some_table" does not exist
Prior to executing the code above, the application works fine (including referencing the table it later complains about). If I remove the try-resource block, and do not close the Connection, everything also works fine, except that I've now created a resource leak. I have also tried explicitly setting the default schema (public) in the following ways:
In the JDBC URL with the currentSchema parameter
With the the spring.datasource.hikari.schema parameter
With the spring.datasource.jpa.properties.hibernate.default_schema property
The last does alleviate the issue with respect to Hibernate managed classes, but the issue persists with native queries. I could, of course, make the schema explicit in those queries, but that doesn't seem to address the root issue. Why would closing a connection trigger this behavior?
My environment:
Spring Boot 2.5.1
PostgreSQL 12.7
Thanks to several users above who immediately saw what I did not. The script, adapted from an older pg_dump run, was indeed mucking with the search_path:
SELECT pg_catalog.set_config('search_path', '', false);
Removing that line, and some other unnecessary ones, resolved the problem. Big duh on my part.
So I've been trying to publish my first project to azure. I've got everything set-up, a service app and a sql database.
My initial page loads properly(It's the standard view for a .net core web application).
The first thing I need to do is register a new user. Whenever I try through my azure app (myapp.azurewebsites.net) it fails and the logs says it's db related.
However I try the same thing by running the application on my machine in production environment, again connected to the azure sql server and everything works perfectly. I can register users, I can create posts, I can edit them. The allow access to azure services option is turned on. This error is from the eventlogs. I have not included the stacktrace.
Category: Microsoft.EntityFrameworkCore.Query EventId: 10100 RequestId: 800001be-0000-ba00-b63f-
84710c7967bb RequestPath: /Identity/Account/Register SpanId: |1e5a93ae-43f424904f38ea9f. TraceId:
1e5a93ae-43f424904f38ea9f ParentId: ActionId: c3430236-e61c-4785-a3c3-4f60ba115b6e ActionName:
/Account/Register An exception occurred while iterating over the results of a query for context type
'MyApp.Data.ApplicationDbContext'. Microsoft.Data.SqlClient.SqlException (0x80131904): Server
name cannot be determined. It must appear as the first segment of the server's dns name
(servername.database.windows.net). Some libraries do not send the server name, in which case the
server name must be included as part of the user name (username#servername). In addition, if both
formats are used, the server names must match.
Those are the different ways I tried to add the connection string to the appsettings.json file. (Server name, catalog, user and password have been replaced, they are written correctly in the appsettings file)
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user#server;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Data Source=tcp:server.database.windows.net,1433;
Initial Catalog=db;User Id=#server.database.windows.net;Password=password;
Alright so after a day and a half, I finally managed to fix it. The solution is rather simple and it is most likely my newbie mistake, that caused so much trouble.
I was following a tutorial for setting up the application and database connection after that. In the tutorial, the connection string that was being used, was the default one, found in the "myApp -> Configuration -> Connection strings", the format was:
Data Source=tcp:server.database.windows.net,1433;
Initial Catalog=db;User Id=#server.database.windows.net;Password=password;
This one was working in the guide, but not for me. So what I did, was go to my "sqldb -> connection strings" and copied the one provided there. I then went back to the app configuration and added it as a new configuration string using SqlServer as the Type.
This string was in the format:
Server=tcp:servername.database.windows.net,1433;Initial Catalog=db;Persist Security Info=False;
User ID=user;Password=mypassword;
MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
After that, the app started working properly.
Using ASP.NET MVC, Entity Framework 6 Code First on SQL Express everything runs fine on my local machine. When I publish to Windows Azure things start to fall apart. The default MVC page displays just fine. And I think the data is correct because I can compare the Azure database with my local SQL Express and everything is identical except for a couple records in __MigrationHistory. This is a new app, so I don't think the other SO issues about converting from previous versions of EF apply.
When I try to access a page that queries the database I get the following exception when I attach the Visual Studio debugger to the Azure web site. It fails on the first call to dbContext.SingleOrDefault. Note that I can see the full data of the dbContext in the debugger when it pauses.
System.Data.SqlClient.SqlException occurred
_HResult=-2146232060
_message=Invalid column name 'CreatedOn'.
HResult=-2146232060
IsTransient=false
Message=Invalid column name 'CreatedOn'.
Source=.Net SqlClient Data Provider
ErrorCode=-2146232060
_doNotReconnect=false
Class=16
LineNumber=2
Number=207
Procedure=""
Server=tcp:*.database.windows.net,1433
State=1
StackTrace:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
InnerException:
Any help would be much appreciated.
Seems like this is something to do with Migrations and the removal of the CreatedOn column.
I get this exception using the MiniProfiler. I deleted the pdb files from the bin folder (as suggested in a post in the MiniProfiler github site) and it no longer happens.
You might want to check references to EF as it could be a reference in a [nuget] package built against an earlier version of EF.
When on my dev machine, all works perfectly. Even using production connection values (so even when I connect to production from the dev machine). I don't think it's a permission problem because I am using the same credentials, just using EF5 instead of linq2sql, as the previous version of the service that worked. Also, the sql-profiler does not show a failed login attempt.
Connection string is:
Data Source=MYSQLSERVER;Database=MYDB;Integrated Security=True;
The error is:
Invalid value for key 'attachdbfilename'.
I have logged the connection string being passed into the dbContext code:
Database.Connection.ConnectionString = settings.DbConnectionHourly;
This is a class that inherits from my real dbContext (which packaged in a dll) and the settings get injected. Again, this works in Dev but not in production (server 2008 r2, IIS 7.5, framework.4).
Turns out that entity framework was trying to be very smart, but it was giving a very un-smart error message. So by convention, if you don't pass the context name in as a constructor, entity framework will assume the classname as the name of the connection string. What it will also do (which I was unaware of), is in development it will automatically connect to and create a schema using the visual studio built in sqlExpress. So in development, everything worked because this 'automagic' creation succeeded and since I later changed the connection to a different database, I was none the wiser about what EF was doing under the covers (EF was doing the wrong things but the end result worked).
However, when the application went to production, there is no sqlexpress or any database on the webserver so the automagic connection/creation sequence failed. Now if the error message had any useful information in it, this would be obvious. But since I had never set an 'attachdbfilename', nor did it tell me what the value of 'attachdbfilename' was or any context or what it was trying to do, this made figuring this out that much more challenging.
The fix was simple:
public HourlyContext(ISettingsWrapper settings)
: base(settings.DbConnectionHourly)
{ }
Instead of setting the connection after the context gets created (the creation process will immediately try to work it's magic with it's built in conventions/defaults), I now set it immediately through the constructor.
We're using Farcry CMS which runs on top of ColdFusion. Site was running fine but we are getting this error message after a web server reboot.
"Failed to initialise core type: dmHTML.cfc"
"Parameter 1 of function IsDefined, which is now application.stcoapi.dmHTML.stWebskins.Copy of displayPageCalculatorSelector.displayname, must be a syntactically valid variable name."
Really not sure where to start, could anyone suggest a strategy for troubleshooting this type of error.
Looks like you have a file called "Copy of displayPageCalculatorSelector.cfm" in your dmHTML webskin folder.
Remove this file is the best option.
Or rename it and remove the spaces, e.g. "Copy_of_displayPageCalculatorSelector.cfm"