tzarger wrote:
First off, thanks for the update and fix!
Otis wrote:
There's a bit of a problem with procs and sqlserver. The Linq to sql designer uses a trick we did too in earlier versions of the sqlserver driver: it tries to determine the resultset of the procs. The downside is that this quite regularly leads to errors when the proc uses a temptable for example. It was so unreliable that we dropped it.
So their designer knows the resultset of most of the procs, and that allows them to map actions of entities onto procs. That's not possible in llblgen pro v2.x, so support for proc calls aren't added to these templates because of this.
Hi Frans, I have been thinking about this response, and ultimately, I think you are a fairly brilliant individual, and you have a great designer that is truly a great piece of software that I have in my toolbelt, and for when it comes down to using LinqToSql (when mandated by the customer), there are some things often times that are out of our control, such as Stored Procedures...
I was thinking, since you have Action and Retrieval Procedures set up in the Designer project, is it not possible to use that information to generate the stored procs on the LinqToSql templates? Let's say worse case scenario, you only script out Action Procedures, as for the most part, they perform a specific function which may be fairly complex that required a stored proc to begin with...
THanks for the compliments
I can emit code for the action procs, that's not a problem. the problem are the retrieval procs.
As far as the Retrieval Procs, perhaps you add a methodology to allow the developer to specify the return types or columns. That information could be optional, and explicitly used in the LinqToSql Templates.
I am just thinking that it might be a good market introduction to get the LinqToSql developers possibly to jump ship and join the LLBLGen family once they realize how great the designer is, and the power of it. But in order to do that, perhaps you might invest some effort on making a complete LinqToSql template output solution.
To effectively use this, the resultset layout of retrieval procs has to be retrieved again, and that's not a picknick (it's doable, but it's buggy). The additional thing to do is to create a layout editor where the user can specify the layout of the resultset.
We won't add that for v2.6, but v3 will get a new designer and we're thinking about adding this as well (as our editors will be rebuild so it's not that hard to add). But for the v2.x designers, mapping procs to entity activities isn't going to happen. That's indeed an area we currently can't handle.
tzarger wrote:
Sorry, another item... It seems if you use SqlMetal to generate the code and you tell it to pluralize, it pluralizes the Table Name, but keeps the Type Name singular.
I notice you mention in previous messages that you are trying to mimic the output of SqlMetal, or Linq Designer, and was curious if this could be implemented as well? [I will give up on the option to add Entity to the type name... :-)]
I've never used sqlmetal
What I initially wanted to do was to get what the linq to sql designer spits out, so you can use the linq to sql code right out of the box. There are currently no 'options' possible, so the templates generate code as defined in the templates.
IMHO, plurification of entity names on the datacontext, as you describe, isn't a good idea. To get it, it is possible, the template has to call into the plurification/singularisation routine and assume the name used is singular. That's not always the case (as users can decide to use plural entity names).