After many handcoded DAOs, I felt again that there should be an easier way to access a database. Doing asp.net stuff at the moment I looked for O/R-mapper and found llblgen. Got some good entries in blogs, so I gave it a try. What lured me were the flash tutorials, which promised a quick start. And the price of <300 EUR for our whole team would be great. Easy to convince managment if you look at Versant ...

At the beginning all was as easy as in the flash demo. I made a mistake when choosing the generator configuration, but I managed to solve this and got my first ABCEntity from the database. Very nice und smooth. The documentation is good to start with, but I would expect a bit deeper documentation on the generated classes. First thing I need was to load all entities from a table. It took me quite some time to find an example. Next thing I remember was to check if a field is NULL. A class documentation of the generated methods would be useful, ok at this very moment I see I could have generated the docs myself.... .

It would be nice to have some SQL-statments on the left side and corresponding statements for selfservice and dataadapter. So one can get an easier start and see wich objects to use to build a query.

hth, martin

moebius wrote:

After many handcoded DAOs, I felt again that there should be an easier way to access a database. Doing asp.net stuff at the moment I looked for O/R-mapper and found llblgen. Got some good entries in blogs, so I gave it a try. What lured me were the flash tutorials, which promised a quick start. And the price of <300 EUR for our whole team would be great. Easy to convince managment if you look at Versant ...

At the beginning all was as easy as in the flash demo. I made a mistake when choosing the generator configuration, but I managed to solve this and got my first ABCEntity from the database. Very nice und smooth. The documentation is good to start with, but I would expect a bit deeper documentation on the generated classes. First thing I need was to load all entities from a table. It took me quite some time to find an example. Next thing I remember was to check if a field is NULL. A class documentation of the generated methods would be useful, ok at this very moment I see I could have generated the docs myself.... .

Did you check out the HowDoI section? This guides you through some of the things you might run into when starting to use the generated code.

The reference manual which is in the installation folder contains the complete documentation of the generated code for adapter and selfservicing, as well as the reference docs for the runtime libraries.

It would be nice to have some SQL-statments on the left side and corresponding statements for selfservice and dataadapter. So one can get an easier start and see wich objects to use to build a query.

These are in the howdoI section. But as with everything in SQL: you can do things in various ways, so it might be the examples aren't a big help in your particular situation while are a big help in others...

The reference manual which is in the installation folder contains the complete documentation of the generated code for adapter and selfservicing, as well as the reference docs for the runtime libraries.

Ah, missed it there. Its not in the help section of the program .... Thanks.

These are in the howdoI section. But as with everything in SQL: you can do things in various ways, so it might be the examples aren't a big help in your particular situation while are a big help in others...

Its more important to convince people that the things they are used to do are possible with the new toy. As a new user I am, I do not know if llblgen can do all the stuff I need. And I always be short on time. So more examples are good to decide quickly go/no go/ try further. The very well written Concepts section is seldom read. A co-worker of mine just wanted to start with another O/R-Mapper, he dropped it when it said it needed a J# hotfix (ok also after he heard my good progress with llblgn).

So I want to see examples where the old way is done with the new stuff. I see wich objects are used, I see the general approach and have a better base to start and I am more confident. There will always be things wich are a tricky but at least the butter&bread stuff is easy.

[sidenote] My co-worker just tried an EntityCollection with datagrid. Good show when setting it as a datasource for a datagrid. Should convince him too

martin

moebius wrote:

These are in the howdoI section. But as with everything in SQL: you can do things in various ways, so it might be the examples aren't a big help in your particular situation while are a big help in others...

Its more important to convince people that the things they are used to do are possible with the new toy. As a new user I am, I do not know if llblgen can do all the stuff I need.

I understand what you mean, though it's hard to find every 'it can do this, but in this form' kind of items, like 'it can do aggregates, though not with MAX(b) but in a different way'.

And I always be short on time. So more examples are good to decide quickly go/no go/ try further. The very well written Concepts section is seldom read. A co-worker of mine just wanted to start with another O/R-Mapper, he dropped it when it said it needed a J# hotfix (ok also after he heard my good progress with llblgn).

It might be an idea to check out the northwind example. As simple as it might look, it does contain some nice feature explanation.

So I want to see examples where the old way is done with the new stuff. I see wich objects are used, I see the general approach and have a better base to start and I am more confident. There will always be things wich are a tricky but at least the butter&bread stuff is easy.

I understand your point. The thing is though that the documentation tries (but sometimes fails, unfortunately) to explain a different approach to look at data, like 'a set of customers' defined by a filter from the big set of customers. So not thinking in SQL but thinking in sets of objects you define subsets in by defining filters.

[quotenick="Otis"]

moebius wrote:

So I want to see examples where the old way is done with the new stuff. I see wich objects are used, I see the general approach and have a better base to start and I am more confident. There will always be things wich are a tricky but at least the butter&bread stuff is easy.

I understand your point. The thing is though that the documentation tries (but sometimes fails, unfortunately) to explain a different approach to look at data, like 'a set of customers' defined by a filter from the big set of customers. So not thinking in SQL but thinking in sets of objects you define subsets in by defining filters.

I see both sides of this issue. I agree with Frans that there isn't an easy way for him to capture all the different query combinations that users run across in the real world. I also agree with Martin (and the many others who have pointed it out) that one of the biggest obstacles to LLBL is trying to crosswalk your SQL knowledge into LLBL syntax.

As a potential improvement to the situation (not necessarily a silver bullet solution), I wonder if things could be improved with a dedicated section of the forum to query syntax? None of the existing forums appear to be explicitly set aside for dealing with syntax issues. Off the top of my head, I would almost recommend something like: A new section specific to queries with the following forums: - Selecting data - Aggregates - Insert data - Update data Those probably aren't the best breakdowns, nor do things break cleanly across those boundaries, but you get the idea. Or maybe even just one dedicated forum. Right now, syntax questions are distributed across the General and Generated Code forums.

I know you probably don't want to make the hierarchy too fine-grained because then it appears to dilute the forum activity (far more impressive to see one forum with >1000 threads than 5 forums < 200 threads). At the same time, because the General and Generated Code forums are utilized so often for so many types of questions, we tend to see the same query questions pop up every now and then primarily because they original posts get lost in the crowd. If things were finer-grained, they might not roll into oblivion quite as easily.

Anyway, I'm sure you've given it some thought in the past, but I just wanted to throw in my two cents.

Matt

good ideas!

We don't care about the # of threads in a forum, it's not a pissing contest . The total amount of messages says enough I think . What counts is the availability of information towards customers. This morning I'll upload the first few links to our knowledge base page, which are searches on the forum, with a single click. The list isn't very large, but will grow over time.