LINQPad 7 (and 6) bug - Unable to compile typed data context - MSSQLSRV db
It seems to be bug in LP6 and LP7.
During expanding connection in Connections tree or openning linqpad query with this connection used, I have got Error message:
(for error deatails see attached file on the end of post..)
After this LP7 Connections Tree shows:
In LP5 can be database expanded without error.
It could be reproduced by creating MSSQLSRV database using sql script:
(in my case MSSQL 2016 and 2017)
USE [master] GO CREATE DATABASE [LP6_n_7_Err] GO USE [LP6_n_7_Err] GO CREATE FUNCTION [dbo].[GetStrAfterChar] ( @searchedStr varchar(250) = null, @char char(1) = null ) RETURNS varchar(250) AS BEGIN IF(@searchedStr IS NULL) RETURN NULL; IF(LEN(@searchedStr) = 1) RETURN NULL; DECLARE @retValue as varchar(250); SET @retValue = SUBSTRING(@searchedStr, COALESCE(NULLIF(CHARINDEX(@char, @searchedStr), 0), LEN(@searchedStr)) + 1, LEN(@searchedStr)) if(LEN(@retValue) = 0) return null; return @retValue; END GO USE [master] GO ALTER DATABASE [LP6_n_7_Err] SET READ_WRITE GO
Strange - I can't reproduce this. I've also tried with Windows Sandbox, connecting to an Azure SQL database upon which I've run your script. LINQPad correctly escapes the "char" parameter name to "@char" as designed.
Thanks for your investigation.
Your difficulties with reproducing the issue directed me to make some other investigation and I found that it depends on Number Formating in Regional settings of Windows.
Part of error message:
directed me to try to change the system Number formating.
When I set Number Format to English (United States)
and restart the LINQPad, the connection is OK without error and the database Function GetStrAfterChar works normally.
When I set the Number format back to my original settings Czech (Czechia)
and after that, I restarted LINQPad, the refreshing of the Connection is crashing.
There are some differences in number separators and list separators. (In Czech, lists are separated by a semicolon instead of a comma in English formating)
Maybe it could be the cause of crashing.
Thanks for that - the Czech locale is indeed the cause (specifically, 'char' comes after 'goto' when comparing strings with Czech culture-sensitive settings). I'll have a fix in the 7.3 beta, which will be out within a few days.
The 7.3.1 beta is out now:
I confirm that the issue has been fixed.
Thanks a lot.