Otis -

We have been using LLBLGen for several months on a very large project with several developers, and are making great progress using it. With that said, I have two requests for enhancements to the designer.

1

We are running into problems with several Stored Procedures being labeled as Action when they are really Retrieval. I read a few posts about the issue, and have implemented the workaround of setting the "Amount of Resultset" property to 1 which works, until we regenerate the project when we do a build.

Is there a way that the designer could look for a specially marked comment in the SP (call it an LLBLGen Hint) that could be set to retrieval or action, that the designer would read, to ensure the SP is put in the appropriate category? We are running into this more and more as SP's are added. The common denominator seems to be when we use temp tables for retrieval of data. These very often are marked as action. I realize you are relying on an ADO function to properly determine the type of SP, but that function often makes erroneous decisions.

2

Our team has chosen to always keep the entity property names in sync with the actual fieldnames in the underlying SQL Server tables as we make changes. In other words, we do not want to allow LLBLGen to automatically attempt to handle fields that have been renamed or changed. We have run into several instances where the designer mistakes one field for another (usually when a table has a field renamed, and a field added or deleted, and the field added or deleted is the same type as the one being renamed). To ensure our entities always mirror what is in the DB, we either must delete and re-add the entities one by one, or we end up starting a new project from scratch. Both of these take time to do.

Is it possible to add an option (possibly globally, but at the very least at the object level) within the designer, so we could designate the objects that we want to have recreated from scratch every time a build is done? I realize there are probably implications to this when customization is done to these objects in the designer (we are not using those features though). This would be extremely helpful for those of us that choose to use LLBLGen in this manner.

Thanks for the consideration.

DPSoft wrote:

Otis -

We have been using LLBLGen for several months on a very large project with several developers, and are making great progress using it. With that said, I have two requests for enhancements to the designer.

1

We are running into problems with several Stored Procedures being labeled as Action when they are really Retrieval. I read a few posts about the issue, and have implemented the workaround of setting the "Amount of Resultset" property to 1 which works, until we regenerate the project when we do a build.

Is there a way that the designer could look for a specially marked comment in the SP (call it an LLBLGen Hint) that could be set to retrieval or action, that the designer would read, to ensure the SP is put in the appropriate category? We are running into this more and more as SP's are added. The common denominator seems to be when we use temp tables for retrieval of data. These very often are marked as action. I realize you are relying on an ADO function to properly determine the type of SP, but that function often makes erroneous decisions.

This will be changed in the upcoming upgrade. In there you will be able to select which procs to read from the db schema's and for each proc you can set the amount of resultsets manually (select a range, for example using the filter, set the amount of resultsets). This also speeds up the refreshing of catalogs tremendously.

Here's a screenshot:

2

Our team has chosen to always keep the entity property names in sync with the actual fieldnames in the underlying SQL Server tables as we make changes. In other words, we do not want to allow LLBLGen to automatically attempt to handle fields that have been renamed or changed. We have run into several instances where the designer mistakes one field for another (usually when a table has a field renamed, and a field added or deleted, and the field added or deleted is the same type as the one being renamed). To ensure our entities always mirror what is in the DB, we either must delete and re-add the entities one by one, or we end up starting a new project from scratch. Both of these take time to do.

Is it possible to add an option (possibly globally, but at the very least at the object level) within the designer, so we could designate the objects that we want to have recreated from scratch every time a build is done? I realize there are probably implications to this when customization is done to these objects in the designer (we are not using those features though). This would be extremely helpful for those of us that choose to use LLBLGen in this manner.

This will also be in the next upgrade. I've already implemented this, but as I'm halfway through the planned features, you have to be patient for a couple of weeks to try it out . You'll be able to set an option to keep entity/field/typedview/typedview field/proc call/ proc param names in sync with the catalog object they're mapped on. Furthermore, you can also set an option to automatically add any new elements in the catalog to the project and other nice options for the refresher, which makes refreshing a catalog much less complicated.

If your impatient like I am for the update (Which looks like it will solve all our problems) I posted a work around:

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=2257

This was to solve a slightly different problem, one of productivity/performance of the process but if you use it and create a small editor like I did it allows you to override the Analysis. Simply edit the cache and use 0 for an Action procedure, or the number of result sets to change an Action to a Retrievial.

What I've noticed and I sent Frans a log of our refresh, is that anything that uses Temp tables gets marked as an Action query, and a few other cases that throw errors.

John

Not a high priority, maybe, but it would be nice to have a search function in the designer. If you rename a field you could easily find all instances of the field. Maybe it would work like the search function in regedit, just take you to the next instance in the treeview.

JimFoye wrote:

Not a high priority, maybe, but it would be nice to have a search function in the designer. If you rename a field you could easily find all instances of the field. Maybe it would work like the search function in regedit, just take you to the next instance in the treeview.

I've implemented a plugin system. This system allows you to write plugins easily which can access the complete project. I think your request is best implemented with a plugin. How to write plugins will be in the upcoming SDK upgrade, and I've written one plugin to illustrate the system (which will add a custom property to a lot of elements)

Otis wrote:

DPSoft wrote:

Otis -

We have been using LLBLGen for several months on a very large project with several developers, and are making great progress using it. With that said, I have two requests for enhancements to the designer.

1

We are running into problems with several Stored Procedures being labeled as Action when they are really Retrieval. I read a few posts about the issue, and have implemented the workaround of setting the "Amount of Resultset" property to 1 which works, until we regenerate the project when we do a build.

Is there a way that the designer could look for a specially marked comment in the SP (call it an LLBLGen Hint) that could be set to retrieval or action, that the designer would read, to ensure the SP is put in the appropriate category? We are running into this more and more as SP's are added. The common denominator seems to be when we use temp tables for retrieval of data. These very often are marked as action. I realize you are relying on an ADO function to properly determine the type of SP, but that function often makes erroneous decisions.

This will be changed in the upcoming upgrade. In there you will be able to select which procs to read from the db schema's and for each proc you can set the amount of resultsets manually (select a range, for example using the filter, set the amount of resultsets). This also speeds up the refreshing of catalogs tremendously.

I ran into this problem with the new LLBLGen version. Is this feature implemented in v2.0.0.0? If so, I can't find it. Do I still have to use a workaround?

Found it: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=6239&HighLight=1

I will throw in my requests:

1) When using Inheritance, would be nice if those inherited entities showed up "under" the correct entity - as sub-nodes and were not in the main root node.

2) As you get large numbers of "things" in the designer, everything starts to run together. What would be nice (for me), is if at the TOP level of the designer I could have a way to "group".

I would create "BlahModule" and under that it would have Entites/TypedLists/TypedViews/ProcCalls.

I could then create "Blah2Module" and have the same Entites/TypedLists/TypedViews/ProcCalls sections.

This would allow me to have just some basic organization of the project in the GUI...

3) When editing custom properties, if you change the "Name" part of a custom property and hit enter, it will revert back to what it was. If you hit Tab, it appears to have changed - but if you close the screen it will revert - evidently there is no way to change the name other than remove/add. The "Value" part works fine.

WayneBrantley wrote:

I will throw in my requests:

1) When using Inheritance, would be nice if those inherited entities showed up "under" the correct entity - as sub-nodes and were not in the main root node.

They're also normal entities, so that's why they're also in the main list. THey're also enlisted under the supertype, under the 'subtypes' node. They're also in the main list to find them back easily.

2) As you get large numbers of "things" in the designer, everything starts to run together. What would be nice (for me), is if at the TOP level of the designer I could have a way to "group".

I would create "BlahModule" and under that it would have Entites/TypedLists/TypedViews/ProcCalls.

I could then create "Blah2Module" and have the same Entites/TypedLists/TypedViews/ProcCalls sections.

This would allow me to have just some basic organization of the project in the GUI...

Wouldn't that end up as simply 1 project per group? If so, why not creating multiple projects on the same database/schema?

3) When editing custom properties, if you change the "Name" part of a custom property and hit enter, it will revert back to what it was. If you hit Tab, it appears to have changed - but if you close the screen it will revert - evidently there is no way to change the name other than remove/add. The "Value" part works fine.

The editor is indeed a bit cumbersome. Grids are nice things to show lists of data but horrible to enter data (at least in .net ). I'll add a todo item for a better custom property editor.

They're also normal entities, so that's why they're also in the main list. THey're also enlisted under the supertype, under the 'subtypes' node. They're also in the main list to find them back easily.

Maybe an option to do this. When doing target per hierarchy and you have quite a few subtypes, I dont really want to see them in the main list - but just under the subtypes grouping...

Wouldn't that end up as simply 1 project per group? If so, why not creating multiple projects on the same database/schema?

Sort of. There are also 'common' entities shared among all the groups and I would have to add them into each project, generate the same code for them - perhaps even add the same partial class extensions into them, etc. For example, if at your company you have web "products". Lets say you have 5 of them. Each of them have their own entities, etc. However, all of them share the "customer" entities and related things. Maybe they also share an "Imaging" group of entities. My intention would be to organize the Imaging, Customer, and each product into folders in the same project.

Have a look at how hard it would be to do this - if not bad, I think it would help. It would not affect code generation or options/relations inside the designer, just display of the items.