fsprojects / SQLProvider

A general F# SQL database erasing type provider, supporting LINQ queries, schema exploration, individuals, CRUD operations and much more besides.
https://fsprojects.github.io/SQLProvider
Other
564 stars 144 forks source link

Dacpac Owner/Schema? #733

Closed Thorium closed 3 years ago

Thorium commented 3 years ago

I'm calling a stored procedure which has a separate schema than the default user. Let's say schema is called reporting. With MsSQL it calls reporting.mysummary but with SSDT it calls only mysummary and what happens is SQL Server responds to me could not find stored procedure mysummary.

Ping @JordanMarr : I expect this is general dacpac-file-parsing issue? Would this also happen with tables, view, etc, if they are not located in the default schema of that user?

Thorium commented 3 years ago

Hmm, this seems to happen only on runtime with sprocs so I expect it's rather a serialization issue of some kind than a parsing issue.

JordanMarr commented 3 years ago

It should be fairly easy to feed your dacpac into the parser unit tests to make sure it is properly parsing the SP schema.

JordanMarr commented 3 years ago

You could point the Parse AdventureWorks dacpac test directly to your dacpac: https://github.com/fsprojects/SQLProvider/blob/master/tests/SqlProvider.Core.Tests/MsSqlSsdt/MsSqlSsdt.Tests/Dacpac/ParseSchemaTests.fs

Thorium commented 3 years ago

MsSQL is picking the following:


    let getSprocName (row:DataRow) =
        let owner = dbUnbox row.["specific_catalog"]
        let (procName, packageName) = (dbUnbox row.["specific_name"], dbUnbox row.["specific_schema"])
        { ProcName = procName; Owner = owner; PackageName = packageName; }
JordanMarr commented 3 years ago

If the SSDT parser is parsing the schema properly, then maybe it is being changed or ignored somewhere along the way. A quick fix could be to intercept Ssdt provider ExecuteSprocCommand / ExecuteSprocCommandAsync methods to make sure that the command.CommandText is set to the proper sproc {schema}.{name}.

Thorium commented 3 years ago

no, ssdt is just setting the schema to Owner and package as empty, I guess package name should also be the schema.

let spName = { ProcName = sp.Name; Owner = sp.Schema; PackageName = String.Empty; }
JordanMarr commented 3 years ago

Oh that makes sense. I do recall being a little confused there.

Thorium commented 3 years ago

Annoyingly there is some caching going on, so if I change anything and copy the local dll to my another projects bin-folder, nothing seems to be getting the changes. That was not the case with SQLProvider 1.1.x

Thorium commented 3 years ago

Fixed in 1.2.3