On Sep 15, 8:56 pm, Travis Duncan <[email protected]> wrote:
>
> Yeah, yeah, we know the drill *points to short story-long stack
> trace*.  So, I guess the question is, does DbLinq always become this
> temperamental when it comes to using method calls in where clauses?

Yes.

> (I tried using just a variable, by the way, and DbLinq decided it
> didn't want to substitute the variable "parameter" as its actual
> value).

It sounds like you have the QueryCache enabled. It caches previous
select queries that DbLinq has converted. It's enabled by default in
version 0.18. The QueryCache has got problems at the moment, see
http://groups.google.com/group/dblinq/browse_thread/thread/c12d07d9aaa0ab69#,
and you should probably disable it or even better check out svn trunk
where it's disabled by default.

One thing which caught me out when starting out was that you MUST
create a new DataContext object for every query. If you don't and your
app is multi-threaded you'll have issues.

I've never been able to work out the DbLinq way to do the create,
update and delete operations and ended up implementing the dynamic
methods in the DataContext class which work well for me.

        public void ExecuteDynamicDelete(object entity) {
            using (DatabaseContext.OpenConnection()) {//ConnMgr will
close connection for us
                //using (IDatabaseTransaction transaction =
DatabaseContext.Transaction()) {
                var queryContext = new QueryContext(this);
                var deleteQuery = QueryBuilder.GetDeleteQuery(entity,
queryContext);
                QueryRunner.Delete(entity, deleteQuery);
                // transaction.Commit();
            }
        }

        public void ExecuteDynamicInsert(object entity) {
            using (DatabaseContext.OpenConnection()) { //ConnMgr will
close connection for us
                //using (IDatabaseTransaction transaction =
DatabaseContext.Transaction()) {
                var queryContext = new QueryContext(this);
                var insertQuery = QueryBuilder.GetInsertQuery(entity,
queryContext);
                QueryRunner.Insert(entity, insertQuery);
                // transaction.Commit();
            }
        }

        public void ExecuteDynamicUpdate(object entity) {
            using (DatabaseContext.OpenConnection()) {//ConnMgr will
close connection for us
                //using (IDatabaseTransaction transaction =
DatabaseContext.Transaction()) {
                var queryContext = new QueryContext(this);
                var updateQuery = QueryBuilder.GetUpdateQuery(entity,
null, queryContext);
                QueryRunner.Update(entity, updateQuery, null);
                //transaction.Commit();
            }
         }

In case it's useful here's how I've ended up hooking up DbLinq in my
project 
http://sipsorcery.codeplex.com/sourcecontrol/changeset/view/27031?projectName=sipsorcery#299625.

By and large it works pretty well. Recently I've had performance
issues with some operations that need to do a high volume of select
queries. Because the QueryCache doesn't work it means DbLinq is going
to be doing a shed load of work for every select. I've reluctantly
reverted to raw SQL for the high volume queries. Apart from that using
LINQ expressions instead of SQL is a dream and the DbLinq library is
doing a wonderful job getting us closer to that utopia!

Regards,

Greyman.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to