Perhaps I've missed something, but I can't find how to change the MSSQL user ("schema owner") without regenerating the code.

When developing locally I use "dbo", but after deployment on my webhotel I have to use another username. This must be pretty common. Optimally, this should be a parameter in the web.config (like connectionstring).

I guess the easiest workaround right now is to use the same username locally?

Thanks for any help.

//Sire

This is added to 1.0.2004.2, which is currently in beta.

As a workaround, (till 1.0.2004.2 is out of beta), rename the schema in the catalog explorer and regenerate the code.

What is the solution in the beta? Does it support to remove (not specify) the owner? We never specify it in the sql and never had any problems. Of course there is one exception (UDF on SQL server) where you have to have the owner, but that's it...

castlejoe wrote:

What is the solution in the beta? Does it support to remove (not specify) the owner? We never specify it in the sql and never had any problems. Of course there is one exception (UDF on SQL server) where you have to have the owner, but that's it...

You can specify from to name pairs (so 'dbo' should become 'foo') in the .config file, and the code takes care of the rest. You can do this for schema's and catalogs.

Maybe I missunderstood you, but you say that you can change the owner but not remove it? The best - for me - is plain "select * from myTable" instead of "select * from foo.myTable". Setting the owner in the config file gets the app running, but we win over our competitors because we don't have to set up things in some .config file before our app is up and running.

Would it be difficult to handle empty string in the config, meaning of course no specified owner (schema/catalog)?

castlejoe wrote:

Maybe I missunderstood you, but you say that you can change the owner but not remove it? The best - for me - is plain "select * from myTable" instead of "select * from foo.myTable". Setting the owner in the config file gets the app running, but we win over our competitors because we don't have to set up things in some .config file before our app is up and running.

Would it be difficult to handle empty string in the config, meaning of course no specified owner (schema/catalog)?

That wouldn't be difficult. I've to add code for that anyway, as it appears specifying an empty string is not working properly.

Though you'll always have to set things up in a config file I guess: the connection string for example.

That sounds great! Thanks.

The connection string is kept encrypted in a different place and I intend sending it as parameter and not let llblgen read it self from the config. The user can choose which db it connects to at login (ex. a customer's UK department has one db running oracle but the D dep. is on sql server, but both use the same app.)...

The 1.0.2004.2 beta now allows empty catalog/schema names for overwriting through the config. So you just define the overwriting in the config ONCE (from your catalog/schema to "") and the connection string will take care of the rest

Hi, Frans. This is a little fussy, but...

There's a property on the DataAccessAdapter called ConnectionStringKeyName which allows you to change which appSetting you're using to get the connection string. In Self-Servicing you use a shared member on DBUtils called ActualConnectionString which is the actual connection string to be used.

Can you add an ActualConnectionString property that would perhaps override the ConnectionStringKeyName property on the Adapter such that all future actions on the Adapter use that string without having to either a)add another key to the .config file or b)pass the new connection string in for each instantion of Adapter? Thanks.

Jeff...

Hmm. You have a point, the connection string tag name is also static, though I'm not really fond of the global connection string static parameter. I fully admit, what's the difference with a global tag name? but with that you can just have 1 string defined in the config file and by changing the tag name you'll be just out of luck, but with a global connection string name, the whole app can suddenly point to another database, which is perhaps not the desired result

I've to think about it. I'd rather avoid adding that global string.