I'm guessing then it's to do with the connection string. Try running this query:
this.Database.GetDbConnection().ConnectionString
If it doesn't output what you expect, go back to the connection properties. Which option did you choose in how LINQPad should instantiate your context?
Via a constructor that accepts a DbConnectionOptions.
There are a couple of different overloads for it but I created one specifically for linqpad.
In the connection window it shows the connection and I can browse the tables and fields, but if you try any query e.g. just drag a table to the query window and execute, this produces an Instance failure.
Linqpad should use the basic constructor which just allows for the connection string, there are 2 more which are dynamic and populate the connections at runtime.
I went back and hard coded a connection string for a different context based on if in Linqpad and that worked, I then tried passing in a string, then a constructor that accepts and these worked.
I went back to the original context and just redid it this now works too.
It doesn't make sense but now works so will just accept it and move on.
Comments
this.Database.GetDbConnection().ConnectionString
If it doesn't output what you expect, go back to the connection properties. Which option did you choose in how LINQPad should instantiate your context?
Via a constructor that accepts a DbConnectionOptions.
There are a couple of different overloads for it but I created one specifically for linqpad.
In the connection window it shows the connection and I can browse the tables and fields, but if you try any query e.g. just drag a table to the query window and execute, this produces an Instance failure.
The differences are from table splitting.
And have you tried testing the constructor overload you created for LINQPad from Visual Studio?
I went back to the original context and just redid it this now works too.
It doesn't make sense but now works so will just accept it and move on.