GetMethodImpl. not support overloads after MSSQL server upgrade

[halcwb]

Describe the bug
Existing code ran without problems. Then the database was moved to a new MSSQL server. There was an upgrade from 2012 to 2019. However, after adjusting the connection string, the problem started with 2 tables: LocalTranslation and LocalTranslation_, so the same table with an underscore. These tables existed on the previous server (2012), but then didn't cause a problem. but know:

GetMethodImpl. not support overloads, name = 'get_LocalTranslation', methods - '[|Method get_LocalTranslation; Method get_LocalTranslation|]'

So, the entire database was just moved, not changed! And the same code with the connection string to the old server compiled, but doesn't compile with the exact same database, only on MSSQL 2019.

To Reproduce
Steps to reproduce the behavior:
Difficult to reproduce. This happened on hospital owned servers.

Expected behavior
Be able to resolve the tables LocalTranslation and LocalTranslation_ as before.

Screenshots
N/A

Desktop (please complete the following information):
.NET SDK (reflecting any global.json):
Version: 6.0.101
Commit: ef49f6213a

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19044
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.101\

Host (useful for support):
Version: 6.0.1
Commit: 3a25a7f1cc

.NET SDKs installed:
5.0.200-preview.21077.7 [C:\Program Files\dotnet\sdk]
5.0.201 [C:\Program Files\dotnet\sdk]
5.0.202 [C:\Program Files\dotnet\sdk]
5.0.404 [C:\Program Files\dotnet\sdk]
6.0.101 [C:\Program Files\dotnet\sdk]

[Thorium]

This is weird as there is no "LocalTranslation" mentioned in SQLProvider code-base.
So a few things:

• The database driver. Are you using the same driver? System.Data.SqlClient.dll?
• Is the Visual Studio / FS in the same runtime environment?
• SQLProvider tries to load database drivers via reflection.
• GetMethodImpl is in ProvidedTypes.fs. That file is borrowed from https://github.com/fsprojects/FSharp.TypeProviders.SDK

[halcwb]

@Thorium. Thanks for looking into this!

• I use the exact same driver: Microsoft.Data.SqlClient.dll
• Exact same environment
• Code is identical, so I use a resultionPath

The mentioned LocalTranslation and LocalTranslation_ are table names! These table names are resolved as methods? by the type provider, I think. But they are interpreted as the same method, see: #748.

Additionally, when I try to use the already compiled code and I want to open a datacontext to the new instance of the database, it seems the compiled code (dll) tries to get access to the old instance of the database that was used to compile the code. So, I try:

#r "nuget: SQLProvider"

// path to the compiled code
#I "../../../libs"
#r "Informedica.MetaVisionServices.Lib.dll"

open Informedica.MetaVisionServices.Lib

// connection string to db on the production server
let connStr = "Data Source=SERVER;Database=DATABASE;User Id=USER_A;Password=PWD;"
Informedica.MetaVisionServices.Lib.DataContext.sql.GetDataContext(connStr)

And I get an error that I cannot login, using the credentials (USER_B) I used to compile the code instead of the credentials in the connection string (USER_B) to the new instance.

C:\Development\Informedica\libs\Informedica.PICURED.Lib\unknown(1,1): error FS3033: The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an
error: Cannot open database "DATABASE" requested by the login. The login failed.
Login failed for user 'USER_B'.

Surely you don't need to have access to the database you use to compile when using the compiled code in production?

[halcwb]

I have written a fix in #748