I had a query working when I wasn't using the async version of the ORMSupportClass dll

It's generating this query

    Query: SELECT [LPA_L1].[ Code], [LPA_L1].[Description], [LPA_L1].[IsActive], [LPA_L1].[ParentCode], [LPA_L1].[Type] FROM (SELECT [LPLA_1].[ Code], [LPLA_1].[Description], [LPLA_1].[IsActive], [LPLA_1].[ParentCode], [LPLA_1].[Type] FROM [LIMSplusv5DB].[iProducts].[vPicklists]  [LPLA_1]  ) [LPA_L1] WHERE ( ( ( ( [LPA_L1].[Type] = p2))))

    Parameter: p2 : String. Length: 4. Precision: 0. Scale: 0. Direction: Input. Value: "City".

The exception is "Invalid column name 'p2'."

This is the code I'm running

  using (var adapter = new DataBaseConnection().DataAccessAdapter)
            {
                var metaData = new LinqMetaData(adapter);
                var data = from v in metaData.VPicklist
                    where v.Type == type.ToString()
                    select v;                       

                return Mapper.Map<List<PickList>>(data);
            }

What am I missing? Please let me know if you need more information. My version of Llblgen is 5.0.8

sorry wrong title it's Invalid column name 'p2' for the title

That should be a parameter, @p2, not 'p2'. This is SQL Server? You use default runtime libs or modified ones?

SQL Server, we use default runtime libraries.

As a quick update, this works...

var metaData = new LinqMetaData(adapter); var data = from v in metaData.VPicklist select v;

This doesn't

 var metaData = new LinqMetaData(adapter);
                var data = from v in metaData.VPicklist
                    where v.Type == type.ToString()
                    select v;

This does too?

var typeAsString = type.ToString();
var metaData = new LinqMetaData(adapter);
                var data = from v in metaData.VPicklist
                    where v.Type == typeAsString
                    select v;

(edit) I can't reproduce it. Works fine in 5.0.10 (latest build, hotfix build available in myaccount->downloads)

[Test]
public void ToStringInWhereClauseTest2()
{
    using(var adapter = new DataAccessAdapter())
    {
        var metaData = new LinqMetaData(adapter);
        var country = 10;
        var q = from c in metaData.Customer
                where c.Country == country.ToString()
                select c;
        var results = q.ToList();
        foreach(var v in q)
        {
        }
    }
}

query generated:

Generated Sql query: 
    Query: SELECT [LPA_L1].[Address], [LPA_L1].[City], [LPA_L1].[CompanyName], [LPA_L1].[ContactName], [LPA_L1].[ContactTitle], [LPA_L1].[Country], [LPA_L1].[CustomerID] AS [CustomerId], [LPA_L1].[Fax], [LPA_L1].[Phone], [LPA_L1].[PostalCode], [LPA_L1].[Region] FROM [Northwind].[dbo].[Customers]  [LPA_L1]   WHERE ( ( [LPA_L1].[Country] = @p1))
    Parameter: @p1 : String. Length: 15. Precision: 0. Scale: 0. Direction: Input. Value: "10".

So I have no idea what's going on, but the parameter name isn't correct, it should have a '@'. Please update to the latest build of 5.0 (or to 5.1).

I updated to the latest version from nuget 5.1.2 . Attached is a screenshot of it, and the problem still happening =(

Hi,

I changed the view from PocoWithLinQuery to TypedDataTable

updated the code to this

var pickList = new VPicklistTypedView();
var bucket = new RelationPredicateBucket();
bucket.PredicateExpression.Add(VPicklistFields.Type == type.ToString());
adapter.FetchTypedView(pickList.GetFieldsInfo(), pickList, bucket, true);

Returns this...

[code]

Query: SELECT [LIMSplusv5DB].[iProducts].[vPicklists].

, [LIMSplusv5DB].[iProducts].[vPicklists].[Type], [LIMSplusv5DB].[iProducts].[vPicklists].[Description], [LIMSplusv5DB].[iProducts].[vPicklists].[ParentCode], [LIMSplusv5DB].[iProducts].[vPicklists].[IsActive] FROM [LIMSplusv5DB].[iProducts].[vPicklists]   WHERE ( [LIMSplusv5DB].[iProducts].[vPicklists].[Type] = p1)
    Parameter: p1 : String. Length: 20. Precision: 0. Scale: 0. Direction: Input. Value: "City".

At first I thought it had to do with maybe the LINQ code generation being the culprit, but it's leading me to believe it might have to do with the actual project being generated.

Gonna try to create a project in a new location, with no nuget packages and see how it turns out. I had this working before, seems kinda odd that updating to a different set of dlls would mess things up.

Maybe I'm not generating proper 4.5 code from LLBLGEN software.

Generating the code in a new folder and having it point to my local dlls "C:\Program Files (x86)\Solutions Design\LLBLGen Pro v5.0\Frameworks\LLBLGen Pro\RuntimeLibraries\CompiledRuntimeLibraries\NET4.5\SD.LLBLGen.Pro.ORMSupportClasses.dll" got it to work again.

Not sure what I need to do to fix this problem.

Ok my boss helped me figure out what the problem is. I'm posting it here in case you guys want to do something about it.

1. First we generate the database projects through LLBLGEN software.
2. Then we add the projects to our visual studio solution
3. We open nuget and get latest version of dll's (This is where things get funky)

Since LLBLGEN creates two projects that are basically sharing resources nuget sees them as two files but they both share the same packages.config. This causes nuget to install the package on the first project and ignores the second one.

To fix it we had to open both project files in notepad and copy the path from the project that has the nuget path and paste it to the project without it.

Basically my DataDbSpecific project had the correct sql dll but the old ormsupportclass.

So anytime we do a future nuget upgrade, we have to remember to update the second project manually.

PS.

I also noticed that the project sharing the same assembly.cs file caused issues with MSBUILD. I updated the code generator to not create this file, so I could do a build on tfs checkin and release.

Thanks

Hmm, that's a weird issue indeed! Yes the shared package.config file issue is a known issue, which we hope will be gone once MS finally moves the .NET full csproj file formats to their new format which includes nuget references. We can't move the csproj files to another folder unfortunately due to backwards compatibility.

You have to do this once though, not every time. the second project references the dll on disk from the folder which is managed by the nuget reference of the first, so update the nuget reference in the first and the second will update its reference as its referencing the same file on disk.. The disconnect between nuget's package.config file and csproj references makes this a bit problematic. Sorry for this confusion!

assemblyinfo.cs files are generated once and are skipped when they exist the next time you generate code. You can share assemblyinfo files for msbuild, we use that too: in the csproj (inside visual studio this is easy to do) add a file as 'link' instead of a real file. See the runtime sourcecode archive for an example. Should work fine.

Glad this is sorted and apologies for the problems!