Search

 


Yeah, right!

LINQ to SQL with dynamically generated Stored Prcedure 4

Posted by Paul McConnon Wed, 20 Feb 2008 13:38:00 GMT

I’ve been using LINQ to SQL which is a very nice feature for .NET. It allows you to very quickly model your database objects as objects in code and return them as strongly typed .NET objects.

Seems to have ‘nicked’ (been inspired by?) quite a few ideas from ActiveRecord for Ruby (and Rails). In fact a lot of the new language features (e.g. predicates as anonymous functions for selection, and iterators) seem to borrow from things learnt by being exposed to dynamic languages. All in all it makes .NET much more fun to work in.

Anyway, I was using all this goodness in a project (VS.NET 2008 Orcas beta) and had all my Entities modelled and could use LINQ to query and transform my entities programmatically. I also had a few Stored procedures mapped as methods of the data context. I ran into a problem when I wanted to generate some SQL on the fly so that users could get adhoc filters of their calls.

I didn’t want to drop out into old style ADO.NET using my DBHandler as i would lose the strong typing etc. I decided to use a QueryReport table (as I’ve done numerous times before) to allow me to do ad-hoc queries without being open to SQL Injection. The table consisted of an ID, Name and SQL field. My Stored procedure could take an ID parameter, look up the SQL and use it to filter the calls table

e.g.
ID           Name                SQL
1            All calls           Select * from Calls Where 1 = 1
2            Open calls          Select * from Calls Where Status = 1
3            Old calls           Select * from Calls Where TimeStamp < DateAdd(d, -14,GetDate())
My stored procedure looked like this
ALTER PROCEDURE [dbo].[spExecStoredQuery] 
    @QueryReportID int = 0
AS
BEGIN
    SET NOCOUNT ON;
    declare @queryText varchar(500)
    select 
        @QueryText = SQL 
    from 
        QueryReports
    where
        id = @QueryReportID

    exec (@querytext)
END

The sp always returned All fields from the Calls table, so I should be able to map it to a Call object in the LINQ designer. I created the stored procedure and went about adding it as a method to the LINQ designer.

My problem occurred when I went to set it’s return value to be of type Call. It wouldn’t let me. The option was disabled and greyed out. I immediately assumed that it was because I had an Exec statement in the stored procedure, and assumed it was either a security issue or the designer could not work out it’s return type. I then removed all the exec code from sp and had it return a straight select * from calls.

This still didn’t work. I then renamed the Stored procedure to spStoredQuery. I added it to the designer and I was then able to set its Return Type to Call. This lead me to believe that the designer didn’t like the ‘exec’ in the name of the Stored Procedure. In order to test this I renamed it back to spExecStoredQuery, but, it still worked okay.

I’ve since played around with different versions and names and have discovered the following

  • The first time you add the sp as a method to the designer it checks for return values to try and guess the output type.
  • If it cannot guess the type, it will not let you set a return type in the designer at all
  • If you delete the method then fix the stored procedure so that it returns a constant return type, the designer caches the previous type and will still not let you set a return type.
  • If you rename the stored procedure and re-add it, it checks again, sees a return type (doesn’t matter what it is) This allows you to manually select a return type in the designer.
  • If you then remove the non-dynamic select, and make the stored procedure dynamic, the method still works, and coerces the return type to be of type you selected.

So, the outcome of all this is: If you are dynamically generating a query in a stored procedure and want to add it as a method with a return type in the LINQ designer, add it first with non-dynamic select (select * from foo), override it’s return type if required, then add the dynamic SQL to stored procedure and you’re laughing.


Adobe Flex EventListener fails on effect sequence 3

Posted by Paul McConnon Fri, 06 Jul 2007 21:39:00 GMT

I recently came across a gotcha when adding an event listener to a Flex effects sequence whose child effects were duplicated.

I had defined an effects sequence and an effect…

e.g.
var spinSequence:Sequence;
var mover:Move = new Move(target);
mover.yBy = -762;
mover.easingFunction = Linear.easeNone;
mover.duration = 1000;
I then added the same effect to the effects sequence multiple times
spinSequence.addChild(mover);
spinSequence.addChild(mover);
spinSequence.addChild(mover);

I then added an event listener to the sequence to be called when the sequence completed…

spinSequence.addEventListener("effectEnd", setComplete);

The effects sequence worked as I expected, chaining the effect 3 times before completing. Unfortunately I found that event listener would only be fired sporadically. Sometimes it would work for a while and then fail. Sometimes ir would fail straight away. I was pulling my hair out for ages (and I don’t got much of that to pull) before I tried creating duplicate events. For testing I just cut and pasted my code, creating 3 seperate Move effects (mover, mover2 and mover3), a la…

var mover:Move = new Move(target);
mover.yBy = -762;
mover.easingFunction = Linear.easeNone;
mover.duration = 1000;
var mover2:Move = new Move(target);
mover2.yBy = -762;
mover2.easingFunction = Linear.easeNone;
mover2.duration = 1000;
var mover3:Move = new Move(target);
mover3.yBy = -762;
mover3.easingFunction = Linear.easeNone;
mover3.duration = 1000;

and added the (now distinct) events to the sequence…

spinSequence.addChild(mover);
spinSequence.addChild(mover2);
spinSequence.addChild(mover3);

Now when adding the event listener, the event fires all the time. I suspect that the issue is one of Garbage Collection, but I’m new to Flex so I could be well wrong.

Anyways, posted this just in case someone else is slowly going bald with the same problem.