Stored Procedures - Slightly Different Name on Server

Posts   
 
    
mshe
User
Posts: 167
Joined: 02-Feb-2006
# Posted on: 15-May-2007 19:58:51   

Hello,

I'm having an issue with stored procedures.

On my development box, my stored procedure is called:

[Database].[dbo].MyProcedureName

On the server, due to some security permissions, the stored procedure runs under a different account:

[Database].[MyServerAccount].MyProcedureName

Notice on dev it's [dbo] and on the server it's [MyServerAccount].

I've manually set the connectionstring in my app.config, but LLBLGen seems to hardcode the [dbo] part.

Is there a way to override it in code? Or even better... let LLBLGen run under the context of the current connection string?

Thanks!

JimHugh
User
Posts: 191
Joined: 16-Nov-2005
# Posted on: 15-May-2007 20:29:01   

One option (assuming you are using the Adapter model) is to look at Catalog Name overwriting and Schema Name overwriting in the docs.


<configuration>
    <appSettings>
        <add key="Main.ConnectionString" value="data source=..."/>
        <add key="SchemaNameUsageSetting" value="1"/>
        <add key="SchemaNameToUse" value="MyServerAccount" />
    </appSettings>
</configuration>


You can also set the Adapter connection string in the Adapter constructor.

If you are using Self Servicing, you can set the connection string at run time using:


// C#
DbUtils.ActualConnectionString = "Datasource=myserver;....";
' VB.NET
DbUtils.ActualConnectionString = "Datasource=myserver;...."

Beware of threading issues!

mshe
User
Posts: 167
Joined: 02-Feb-2006
# Posted on: 15-May-2007 20:39:03   

My understanding is that SchemaOverwriting is global? Is there a way to set it on a per entity (or SP) basis?

BTW, I'm using the adapter model.

JimHugh
User
Posts: 191
Joined: 16-Nov-2005
# Posted on: 15-May-2007 21:06:02   

Schema overwriting is global.

What you could do is create a new adapter class that inherits from the LLBLGen generated adapter. Here I've called it DMAdapter.

In the CustomConnectionString function, you can use the dotnet 2.0 SqlConnectionStringBuilder (or roll your own) to modify the connection string on the fly.

base.ConnectionString will contain the connection string that LLBLGen obtained from the config file.

You could then manipulate the scsb object to rework the connection string to your hearts content.

Use the derived DMadapter class when calling your special proc.

or you could just put in your own connection string when you create the generated adapter as I suggested at first. I like the derived approach because is centralizes the connetion string setting.


using System;
using System.Data;
using System.Data.SqlClient;
using System.Security.Principal;

using YOURDAL.DatabaseSpecific;

using SD.LLBLGen.Pro.ORMSupportClasses;

public class DMAdapter : DataAccessAdapter
{
    private string CustomConnectionString()
    {
        SqlConnectionStringBuilder scsb = new SqlConnectionStringBuilder(base.ConnectionString);
        string username = WindowsIdentity.GetCurrent().Name.ToString();
        scsb.ApplicationName = string.Format("Data Module : {0}", username);
        return scsb.ConnectionString;
    }

    private void init()
    {
        ConnectionString = CustomConnectionString();
        CommandTimeOut = 60;
    }

    public DMAdapter()
    {
        init();
    }

    public DMAdapter(bool keepConnectionOpen)
        : base(keepConnectionOpen)
    {
        init();
    }
}

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39914
Joined: 17-Aug-2003
# Posted on: 16-May-2007 11:41:47   

Schema overwriting is per DataAccessAdapter instance if you set it directly on that DataAccessAdapter instance. Otherwise the settings from the config file are used which are indeed global.

Frans Bouma | Lead developer LLBLGen Pro
mshe
User
Posts: 167
Joined: 02-Feb-2006
# Posted on: 16-May-2007 17:12:55   

Otis wrote:

Schema overwriting is per DataAccessAdapter instance if you set it directly on that DataAccessAdapter instance. Otherwise the settings from the config file are used which are indeed global.

Good to know - Thanks Otis for the clarification :-)

I think the fact that I can set it in code without hardcoding it in a config file may have solved my issue.