Closed Thorium closed 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.
It should be fairly easy to feed your dacpac into the parser unit tests to make sure it is properly parsing the SP schema.
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
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; }
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}.
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; }
Oh that makes sense. I do recall being a little confused there.
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
Fixed in 1.2.3
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 onlymysummary
and what happens is SQL Server responds to mecould 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?