After executing FetchTypedList, LLBLGen executes the following SQL statement and no rows are returned (please see statement below). After some research, I found it will return rows if "@CrsCde4 nvarchar(3)" is changed to "@CrsCde4 char(3)". I'm not sure why it would work with char but not nvarchar. Does anyone know if this a bug/ known issue or if there anything I can do differently? Thanks.

exec sp_executesql N'SELECT DISTINCT [dbo].[ICS_COURSE_SEARCH_V].[yr_cde] AS [YrCde],[dbo].[ICS_COURSE_SEARCH_V].[trm_cde] AS [TrmCde],[dbo].[ICS_COURSE_SEARCH_V].[subterm_cde] AS [CrsCde], .... WHERE ( [dbo].[ICS_COURSE_SEARCH_V].[yr_cde] = @YrCde1 And [dbo].[ICS_COURSE_SEARCH_V].[trm_cde] = @TrmCde2 And [dbo].[ICS_COURSE_SEARCH_V].[division_cde] = @DivisionCde3 And [dbo].[ICS_COURSE_SEARCH_V].[crs_cde] LIKE @CrsCde4) ORDER BY [dbo].[ICS_COURSE_SEARCH_V].[crs_cde] ASC', N'@YrCde1 char(4),@TrmCde2 char(2),@DivisionCde3 char(2),@CrsCde4 nvarchar(3)', @YrCde1 = '2005', @TrmCde2 = '10', @DivisionCde3 = 'U ', @CrsCde4 = N'%01'

Please check the version of your runtime library dll. (right mouse button on the dll -> properties -> version tab). It's likely you're using a rather old dll.

Should I check SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll? Or is there another runtime DLL to check? By the way, the version of this DLL is 1.0.2004.2. Is this old? The most recent version I know about was just released in October (1.0.2005.1).

Thanks so much for the quick response!

Adam wrote:

Should I check SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll? Or is there another runtime DLL to check? By the way, the version of this DLL is 1.0.2004.2. Is this old?

That's an older version. You should check SD.LLBLGen.Pro.ORMSupportClasses.NET11.dll

There has been a fix for this for quite some time for this, please download the latest 1.0.2004.2 runtime libraries from the customer area -> runtime libraries section, and then please download the 1.0.2004.2 version archive (scroll down). The versions at the top of the list are the 1.0.2005.1 versions.

Unfortunately I am still having problems even after downloading and installing the latest version (1.0.2005.1). After I installed, I regenerated all of my code, compiled, created new DLLs and even rebooted for good measure. I also made sure that I deleted old LLBLGEN references in my projects and pointed to the new runtime DLLs.

I am using the "FieldLikePredicate" expresssion -- is that causing the code to create nvarchar(3) instead of varchar(3)/char(3)?

After some research, I now understand why nvarchar won't work with the char data type (from the SQL Server Books Online):

When you use Unicode data (nchar or nvarchar data types) with LIKE, trailing blanks are significant

Anyway, can you think of anything that I am doing wrong, or is there some sort of work-around? Thanks in advance.

It should select the type of the field, thus char if the field is char etc. So it's a bit strange it doesn't do that in your situation...

Could you give more specifics so we can build a repro case?

Basically I am using a Typed View (which is selecting from a view named ICS_COURSE_SEARCH_V). When I run sp_help on the view, the column is char(30). When I go into the LLBLGen designer, it also recognizes that the column is char(30).

We are building a "search" gui and the piece of code that adds the LIKE expression is:

switch ( exactLike )
    {
        case CRMConstants.CS_EXACT_MATCH:
            courseSearchPredicate.PredicateExpression.AddWithAnd(new FieldCompareValuePredicate(EntityFieldFactory.Create(IcsCourseSearchVFieldIndex.CrsCde), null, ComparisonOperator.Equal, searchText ));
            break;
        case CRMConstants.CS_BEGINS_WITH:
            courseSearchPredicate.PredicateExpression.AddWithAnd(new FieldLikePredicate(EntityFieldFactory.Create(IcsCourseSearchVFieldIndex.CrsCde), null, searchText.Trim() + "%" ));
            break;
        case CRMConstants.CS_ENDS_WITH:
            courseSearchPredicate.PredicateExpression.AddWithAnd(new FieldLikePredicate(EntityFieldFactory.Create(IcsCourseSearchVFieldIndex.CrsCde), null, "%" + searchText.Trim() ));
            break;
        case CRMConstants.CS_CONTAINS:
            courseSearchPredicate.PredicateExpression.AddWithAnd(new FieldLikePredicate(EntityFieldFactory.Create(IcsCourseSearchVFieldIndex.CrsCde), null, "%" + searchText.Trim() + "%" ));
            break;
    }

Here's the line of code that performs the fetch and utlimately creates the call to sp_executesql:

adapter.FetchTypedList(fields, courseSearchResults, courseSearchPredicate, 0, sorter, false);

Please let me know if you need more details. If you would like my email address, just let me know. Thanks again!

By the way, I'm looking forward to using the new type converter functionality. Thanks for including it in this release (1.0.2005.1)!

I noticed something here, and correct me please if I' wrong: You are using a Typed View yet you call FetchTypedList instead of FetchTypedView!!

If it's a typed view, you should use code simmilar to this one:

InvoicesTypedView invoices = new InvoicesTypedView();
DataAccessAdapter adapter = new DataAccessAdapter();
adapter.FetchTypedView(invoices.GetFieldsInfo(), invoices);

This is the the simplest overload, for sure you can add other parameters but please make sure you pass this as the first parameter invoices.GetFieldsInfo()

This is true for FetchTypedList() too What would change beside the function name is the type of the object passed, in my example that would be

InvoicesTypedList invoices = new InvoicesTypedList()

It's a bug in 1.0.2005.1

In 1.0.2004.2, this bug was fixed, the bugfix code is still in 1.0.2005.1, but FieldLikePredicate calls the wrong overload again. Apparently a fix which wasn't migrated back to the 1.0.2005.1 codebase.

Basicly it has to pass on the column type of the field but in 1.0.2005.1 it again doesn't do that and calls the like parameter creation routine without that parameter, which defaults to nvarchar on sqlserver.

Fixed in next build.

Thanks! How often do builds come out? Just trying to plan.

By the way, if I used FetchTypedView() instead of FetchTypedList(), will that make a difference in the way the SQL is generated? Thanks again to both of you!

Adam wrote:

Thanks! How often do builds come out? Just trying to plan.

When they are needed, for example when a major bug was found and fixed. WHen a bug is minor, a build is often postponed till later in the week or next week so more minor issues can be gathered and solved (if applicable, of course). I could mail you a hotfix if you want to. Just post the .NET version number you're using, and I'll mail you a build to the email address you used to register on the forum.

By the way, if I used FetchTypedView() instead of FetchTypedList(), will that make a difference in the way the SQL is generated? Thanks again to both of you!

That shouldn't make that much of a difference in this case, though it's best to call the methods which are specially created for a given type of element, like a typedlist/view/collection etc.

I'm running version 1.1 SP1 of the .NET framework. If you can email a hotfix in the near future, that would be great!

Because I am relatively new to LLBLGen (6 months), I am curious to know about the release cycle. Will there be a more "tested" release or service pack in the near future (like 1.0.2005.2)? We are in the middle of our own QA cycle for our product that is now using LLBLGen and I'd prefer to wait for a more full release. If it is a few months out, I can just go with the hotfix or the more recent versions of 1.0.2004.2.

Thanks again for your quick responses and great support!

Adam wrote:

I'm running version 1.1 SP1 of the .NET framework. If you can email a hotfix in the near future, that would be great!

I'll mail you later today.

Because I am relatively new to LLBLGen (6 months), I am curious to know about the release cycle. Will there be a more "tested" release or service pack in the near future (like 1.0.2005.2)? We are in the middle of our own QA cycle for our product that is now using LLBLGen and I'd prefer to wait for a more full release. If it is a few months out, I can just go with the hotfix or the more recent versions of 1.0.2004.2.

We don't do service packs, we release bugfixes when they're needed, and they're run against our full test base to ensure we don't break anything. A major version, 1.0.2005.1 for example, is a fixed set of features, and we regularly don't change those (only in a very rare exceptional case where a change doesn't break anything) for new functionality, we just fix bugs a.s.a.p. in those releases and release the bugfix to the customers. If required (for example if it's a bugfix which requires additional testing in the situation the customer is in), we first mail the fixed code to the customer to see if it additionally succeeds their tests. After everything is approved, we release a new build onto the website. This thus means we try to get a bugfix in the hands of our customers a.s.a.p. as we don't like to wait for fixes also when we are then one experiencing bugs (hey microsoft!) .

It's rare that a bugfix requires a lot of code change, and when that happens we release a real hotfix, which means it's released separately on the customer area.

The hotfix I'll mail you is a release build of the code which hasn't been pushed through our full tests yet. The fix contains a call to another overload which is already there since july 2005 in 1.0.2004.2 but in 1.0.2005.1, the call to the overload wasnt added, though in 1.0.2004.2 it's there, so not a groundbraking change in the 1.0.2005.1 code.

Thanks again for your quick responses and great support!

You're welcome

(edit) mailed to your yahoo account.