All right, I just downloaded the demo version yesterday and I'm quite impressed. I'm recommending a purchase.

I have one problem that I'm trying to get around but it seems like it's taking me way too long. I generated some code that I'm trying to use and I want to use my own connect string that I generate at runtime. I see many references to DataAccessAdapter, however, I don't have that class anywhere. So it appears as if I'm using the SelfService stuff (and I'm still trying to figure out what the better path for that is). Do I have to use the Adapter route if I want to change the connect string at runtime.

Thanks for the direction, help and a good product.

Ok, I think I've figured the only way to do this was to switch to the Adapter instead of SelfServicing. Are there any drawbacks from switching to this template group?

Hi, there. Otis (LLBLGen's author) is probably either watching soccer or sleeping right now (the bastard) so I'll do what I can. Basically the differences between Adapter and Self-Servicing come down to ease of use vs. abstraction. Self-servicing is VERY easy to use, supports dynamic/lazy-loading, etc. Adapter requires related entities and collections to be loaded/fetched manually, but abstracts the entity from the data source such that you can support multi-tier development better. It also has better support for multi-catalog/multi-connection string architectures, remoting, and inheritance (much better support for inheritance). It's your choice as to which template to use depending on your specific needs. Give 'em both a try; the difference in their approaches becomes obvious very quickly.

Hope this helps.

Jeff...

Thanks for the reply. Yes, it's Friday night/Saturday morning for some, so I wasn't expecting too much in the way of a reply. Yes, I have noticed the differences very quickly and have read some messages where folks aren't bothered by the little extra work that they have to do for the flexibility of the Adapter method.

So you're stating for the record that to support my own dynamic connection string I must absolutely use adapter? If that's the case, then my decision is already made as this is a requirement.

Thanks again for the response.

Look at the documentation's "Best practices..." section. It states that by default the connection string comes from the *.config file. It also states that you can override it if you use the DataAccessAdapter. No mention of how to override using self-sevice.

From previous posts, I see more people saying that they wished they would have used adapter then self-service. (okay, go ahead and flame me for self-service bashing )

billb wrote:

So you're stating for the record that to support my own dynamic connection string I must absolutely use adapter?

Nope, I'm not saying that. I believe it's possible; Self-servicing just doesn't have as good support for it. See this thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=908

The dbutils class is where the connection string is fetched from, and - I believe - you can change how that mechanism works however you want. I'm pretty sure the connection string is read in on each transaction, but I'm not sure. You'd have to track through code to see how/if the connection object is stored.

The advantage Adapter has is that the transaction methods all have overloads that accept a connection string - for the ultimate in flexibility.

Jeff...

Fair enough. I noticed where it was picking it up in SelfService (thanks to the debugger) but I just have a real aversion to changing generated code. It seems if generated code has to change someone is doing something wrong and my first guess is that it's me.

jeffreygg wrote:

billb wrote:

So you're stating for the record that to support my own dynamic connection string I must absolutely use adapter?

Nope, I'm not saying that. I believe it's possible; Self-servicing just doesn't have as good support for it. See this thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=908

The dbutils class is where the connection string is fetched from, and - I believe - you can change how that mechanism works however you want. I'm pretty sure the connection string is read in on each transaction, but I'm not sure. You'd have to track through code to see how/if the connection object is stored.

The advantage Adapter has is that the transaction methods all have overloads that accept a connection string - for the ultimate in flexibility.

Jeff...

billb wrote:

All right, I just downloaded the demo version yesterday and I'm quite impressed. I'm recommending a purchase.

I have one problem that I'm trying to get around but it seems like it's taking me way too long. I generated some code that I'm trying to use and I want to use my own connect string that I generate at runtime. I see many references to DataAccessAdapter, however, I don't have that class anywhere. So it appears as if I'm using the SelfService stuff (and I'm still trying to figure out what the better path for that is). Do I have to use the Adapter route if I want to change the connect string at runtime. Thanks for the direction, help and a good product.

SelfServicing is not that good for doing this, adapter is meant for this. It's however a question why you want to change the connection string at runtime. The reason I ask this is: is it for database selection at runtime (user opens a client, selects the db to work with from a drop down box, and your app connects) or is it for selecting a userid/password at runtime?

You can alter the dbutils.template for example to use this in selfservicing: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=167

This sets a static property in dbutils which is then used in all the code. What I meant with my question was: if you're switching databases at runtime, it can be that schema's are different so code will not work. Adapter solves this as it keeps 1 store for persistence information per db you connect to (oracle and sqlserver for example). You can also use just 1 generated project and pass a different connection string to the DataAccessAdapter constructor.

To alter the dbutils template: (I use sqlserver and C# as an example here) - create a copy of dbUtils.template in drivers\SqlServer\Templates\C# and call it for example dbUtilsDynConStr.template - create a copy of CSharpTemplateSet.config in drivers\SqlServer\Templates and call it for example CSharpTemplateSetCustom.config - open CSharpTemplateSetCustom.config in a texteditor, it's XML - change the name tag value so you will recognize it in the generator config window - in CSharpTemplateSetCustom.config alter the filename in the binding of SD_DbUtilsTemplate to dbUtilsDynConStr.template. Save CSharpTemplateSetCustom.config. - open dbUtilsDynConStr.template in a texteditor. Add the static property as stated in the thread above. Save the template file. - in LLBLGen Pro you can now select your own template set when you press F7. When you generate code now using teh selfservicing configurations (Two class scenario for example) you'll get a dbUtils.cs class which contains the additions you made to the template.

Using the static property solution with SelfServicing has a disadvantage: all calls done are using that connection string. So if you want to switch on a per-call basis you have to use Adapter.

You can switch from selfservicing to adapter without much effort (except you can't use lazy loading with adapter). Selfservicing is easier to learn and the problems most people have is with formulating predicate filters, which is the same for adapter or selfservicing (adapter uses a combined Relationcollection - predicate collection object, but that's it)

billb wrote:

Thanks for the reply. Yes, it's Friday night/Saturday morning for some, so I wasn't expecting too much in the way of a reply. Yes, I have noticed the differences very quickly and have read some messages where folks aren't bothered by the little extra work that they have to do for the flexibility of the Adapter method.

That extra work is addressed soon, when prefetch paths are added to adapter. The extra work is there, but only for fetches.

So you're stating for the record that to support my own dynamic connection string I must absolutely use adapter? If that's the case, then my decision is already made as this is a requirement. Thanks again for the response.

You can use selfservicing with a dynamic connection string, it depends on how you want to use the connection string If you're connecting once per session to a db of choice, like when the winforms app starts, you can use selfservicing with the connectionstring set using the template change I mentioned earlier. If you have to connect to different databases on a per call basis, it's not reliable to do it that way, as all calls use the same connection string in selfservicing.

Thank you for all of the very informative replies. It is possible to switch databases at runtime. Fortunately, I was able to move all of my code that I wrote on Thursday and have it moved to the adapter by the end of the day yesterday. And this still puts me way ahead of schedule now

Otis wrote:

billb wrote:

Thanks for the reply. Yes, it's Friday night/Saturday morning for some, so I wasn't expecting too much in the way of a reply. Yes, I have noticed the differences very quickly and have read some messages where folks aren't bothered by the little extra work that they have to do for the flexibility of the Adapter method.

That extra work is addressed soon, when prefetch paths are added to adapter. The extra work is there, but only for fetches.

So you're stating for the record that to support my own dynamic connection string I must absolutely use adapter? If that's the case, then my decision is already made as this is a requirement. Thanks again for the response.

You can use selfservicing with a dynamic connection string, it depends on how you want to use the connection string If you're connecting once per session to a db of choice, like when the winforms app starts, you can use selfservicing with the connectionstring set using the template change I mentioned earlier. If you have to connect to different databases on a per call basis, it's not reliable to do it that way, as all calls use the same connection string in selfservicing.