Hi!

In my first attempts to use the Predicates I fail miserably. I suppose I do something wrong, but my code is based on the examples, so I do not know how.

Below is some code that binds a typed list to a grid. It works well when the predicate is not invoked, but when I try to filter I get the following error:

"Object reference not set to an instance of an object."

Last time I ran it I got this error:

"An attempt was made to load a program with an incorrect format."

I don't know what I am doing wrong. Can anyone see what I do wrong in my code?

Regards,

!Rob

private void BindGrid(int iPageIndex, string sFilterData)
{
    MenuItems_AllPerUserTypedList menuitem = new MenuItems_AllPerUserTypedList();
    if(sFilterData != "")
    {
        IPredicateExpression filter = new PredicateExpression();
        FieldLikePredicate filterElement = PredicateFactory.Like(
            MenuItemFieldIndex.Name, sFilterData);
        filter.Add(filterElement);

        ISortExpression sorter = new SortExpression(
            SortClauseFactory.Create(MenuItemFieldIndex.Name, SortOperator.Ascending));
        menuitem.Fill(0, sorter, true, filter);
    }
    else
    {
        menuitem.Fill();
    }

    grd.DataSource = menuitem;
    grd.DataBind();

    if(iPageIndex > 0) 
        grd.DisplayLayout.Pager.CurrentPageIndex = iPageIndex;
}

Btw, I might add to my own post by asking if there is no way to add a filter predicate without a sort dito? I don't want to sort my result set, I want to filter it.

!Rob

You can pass null if you don't want to sort.

The code looks ok at first glance. The second error you get is very weird. Could you make sure that you're referencing the .NET11 versions of the runtimes?

Also, if you run into an error like Object not set to a reference.. , please paste the stack trace of the exception as well, so I can see where the exception is thrown.

Hi Otis!

Good that it's possible to pass null for the sorting. I wasn't sure since I got that particular error message. It could have been because of the null I mean. But it isn't then, good!

Regarding the templates, I use the following:

Name: Two class scenario (Full) Vs.Net 2003 Version: 1.0.2004.1.053104 Vendor: Solutions Design Description: SelfServicing. Generates code for the scenario with two classes per entity: one base class and one entity class to work with. Use this configuration to START your project as it generates all classes, including the entity classes using the entity base classes. When you have altered these entity base class using entity classes, use Two Class Scenario Base Only for your further code generation of your project. Will overwrite all classes to generate. Validator classes are initially created but never overwritten. It will also create a VS.NET 2003 project file, however will never overwrite this file. Amount of tasks: 39

This is the Exception.Message: "An attempt was made to load a program with an incorrect format."

I have been getting that one lately, but earlier it was always: "Object reference not set to an instance of an object."

This is the stack trace:

" at SD.LLBLGen.Pro.ORMSupportClasses.Predicate.ToQueryText(Int32& uniqueMarker)\r\n at SD.LLBLGen.Pro.DQE.SqlServer.DynamicQueryEngine.CreateSelectDQ(IEntityFieldCore[] selectList, IFieldPersistenceInfo[] fieldsPersistenceInfo, IDbConnection connectionToUse, IPredicate selectFilter, Int64 maxNumberOfItemsToReturn, ISortExpression sortClauses, IGroupByCollection groupByClause, Boolean allowDuplicates)\r\n at SD.LLBLGen.Pro.DQE.SqlServer.DynamicQueryEngine.CreateSelectDQ(IEntityFieldCore[] selectList, IFieldPersistenceInfo[] fieldsPersistenceInfo, IDbConnection connectionToUse, IPredicate selectFilter, Int64 maxNumberOfItemsToReturn, ISortExpression sortClauses, IRelationCollection relationsToWalk, Boolean allowDuplicates, IGroupByCollection groupByClause)\r\n at SD.LLBLGen.Pro.DQE.SqlServer.DynamicQueryEngine.CreateSelectDQ(IEntityFields selectList, IDbConnection connectionToUse, IPredicate selectFilter, Int64 maxNumberOfItemsToReturn, ISortExpression sortClauses, IRelationCollection relationsToWalk, B oolean allowDuplicates, IGroupByCollection groupByClause)\r\n at netTryst.BusinessLayer.DaoClasses.TypedListDAO.GetMultiAsDataTable(IEntityFields fieldsToReturn, DataTable tableToFill, Int64 maxNumberOfItemsToReturn, ISortExpression sortClauses, IPredicate selectFilter, IRelationCollection relations, Boolean allowDuplicates, IGroupByCollection groupByClause, ITransaction transactionToUse) in c:\documents and settings\robert eliaffon\my documents\visual studio projects\nettryst_dev\generated\daoclasses\typedlistdao.cs:line 72"

Hopefully you can shed some light on the subject.

It's likely you reference the .NET 1.0 versions of the runtime libraries (at least that's what I think), because of the obscure error you get (An attempt was made to load a program with an incorrect format), although googling on the issue it shows mostly native win32 dll issues..

I've tried to reproduce what you did but here it works fine so I think it's something with the dlls not being the right version. If you reference the .NET 1.0 libraries from a .NET 1.1 project, you'll run into weird errors... It's weird as Predicate.ToQueryText() is an abstract method, implemented in teh FieldLikePredicate class you're using, however the stacktrace isn't reaching that class...

So, how do I check what version of .NET I am referencing?

Rob wrote:

So, how do I check what version of .NET I am referencing?

In your vs.net projects. Check if you're referencing SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll, not the .NET10 variant. As well as the DQE assembly. You can verify that by clicking the reference and then check the properties window in vs.net.

ORM Support Identity: SD.LLBLGen.Pro.ORMSupportClasses.NET11 Runtime version: v1.1.4322 Version: 1.0.2003.3

DQE Identity: SD.LLBLGen.Pro.DQE.SqlServer.NET11 Runtime version: v1.1.4322 Version: 1.0.2003.3

I am noticing that the version is 1.0.2003.3, shouldn't it be 1.0.2004... ?

It should be 1.0.2004.1 if you're using the very latest code and thus the runtimes released last weekend. If you're using an installment prior to that date (so LLBLGen Pro's date in hte about box is < 24th of september), it should be 1.0.2003.3

It's likely there is a version mismatch somewhere. So for example in the generated code you reference 1.0.2004.1 and in your own code using the generated code you reference 1.0.2003.3.

Ok, I am downloading the latest version under the download section as I am typing this. If I uninstall the version currently installed, delete my generated project. Install the new version (that is currently downloading) and regenerate the code, will it work then?

Please tell me I do not need to (again) create a new LLBLGen project.

Rob wrote:

Ok, I am downloading the latest version under the download section as I am typing this. If I uninstall the version currently installed, delete my generated project. Install the new version (that is currently downloading) and regenerate the code, will it work then?

I don't know what the cause is of your error however I expect a version mismatch somewhere. When you start using the new version, be sure to update ALL references to the ormsupport classes to the new version, also update a dll in the bin folder of the webapplication, if you're working on a webapplication.

Please tell me I do not need to (again) create a new LLBLGen project.

No, just regenerate the code would do

Ok, after having fiddled around with version for a while now it appears that the version problems might be solved.

However...

Now I get a new shiny problem. Below is code generated in the file: RelationClasses\UserRelations.cs

        /// <summary>
        /// Returns a new IEntityRelation object, between UserEntity and UserEntity over the m:1 relation they have,
        /// using the relation between the fields:
        /// User.CreatedUserID - User.UserID
        /// </summary>
        public IEntityRelation UserEntityUsingUserID
        {
            get
            {
                IEntityRelation relation = new EntityRelation(RelationType.ManyToOne);
                relation.StartEntityIsPkSide = false;

                
                relation.AddEntityFieldPair(EntityFieldFactory.Create(UserFieldIndex.UserID), 
                        EntityFieldFactory.Create(UserFieldIndex.CreatedUserID));
                return relation;
            }
        }
    
        /// <summary>
        /// Returns a new IEntityRelation object, between UserEntity and UserEntity over the m:1 relation they have,
        /// using the relation between the fields:
        /// User.UpdatedUserID - User.UserID
        /// </summary>
        public IEntityRelation UserEntityUsingUserID
        {
            get
            {
                IEntityRelation relation = new EntityRelation(RelationType.ManyToOne);
                relation.StartEntityIsPkSide = false;

                
                relation.AddEntityFieldPair(EntityFieldFactory.Create(UserFieldIndex.UserID), 
                        EntityFieldFactory.Create(UserFieldIndex.UpdatedUserID));
                return relation;
            }
        }

Please note how the IEntityRelation UserEntityUsingUserID is declared in both procs.

To me, this appears to be a bug. What do you think?

Hey Otis!

As much as I would like to claim that my previous post is a bug, I have found that if I hide those relations, the code compiles. That's the important thing for me for right now. So I consider this issue resolved for now.

I appreciated the help today, thank you.

!Rob

Rob wrote:

Hey Otis!

As much as I would like to claim that my previous post is a bug, I have found that if I hide those relations, the code compiles. That's the important thing for me for right now. So I consider this issue resolved for now.

I appreciated the help today, thank you.

That is a solution, but it will also hide the fields mapped on these relations so traversing the graph will be harder. (but not that hard, as hte fields are in the same table, so you don't need a relation object to grab the data)

The problem is that the relation property names are build up using the following scheme: <RelatedEntityName>EntityUsing<fieldnames>

A 1:n relation has an equivalent m:1 relation. If the relation is with self, as is the case here, the 1:n relation property name is: UserEntityUsingCreatedUserID, using the fields of the endpoint of the relation, i.e. the FK side. This to prevent multiple 1:n relations in 1 entity to the same pk entity getting the same name.

The counterparts, the m:1 relation will therefore also use the FK side fields in the name. However for an entity which has multiple relations with itself, it is not possible, as that name will already exist, namely the 1:n relation property

So I opted for the PK side fields in that particular case, which made my testproject compile. Needless to say, this fails when you have 2 or more relations with self.

In prior versions (1.0.2003.3 targetting templates) these relations were skipped, so the problem wasn't there. However I enabled them in this version, and then you run the risk of having this problem. I'll fix this a.s.a.p. as a fix will cause a code breakage for the few who have relations with self and have own filters using these new relations (pretty unlikely, but you'll never know). The fix will likely include a word to make the two relations have different names.

I've uploaded a fix for this. You should go to the templates section and download the SharedTemplates archive (6th item on the list), unzip it in the SharedTemplates folder and regenerate your code (you can thus re-enable the relations).