Receiving null values from Dapper QueryAsync returned cursor

Question

I'm having an issue with one of my dapper calls returning a cursor with all of the column data as null .

We have several calls that look identical to this one, which return a list of the provided model. I'm still getting familiar with C#, .Net, and Dapper, so there could be something simple that I'm missing.

Our SQL stored procedure expects:

Procedure ListItemGrid(pUserId     in number,
                       pListType   in varchar2,
                       pSearchTerm in varchar2,
                       pId         in varchar2,
                       pOut        out sys_refcursor
                       )

The Dapper call:

        public async Task<List<ListItem>> ListItemGrid(string id, string listType = null, string searchTerm = null)
        {
            using (var conn = this.GetConnection())
            {
                var p = new OracleDynamicParameters();
                p.Add("pUserId", value: this.userResolverService.UserId, dbType: OracleDbType.Double, direction: ParameterDirection.Input);
                p.Add("pListType", value: listType, dbType: OracleDbType.Varchar2, size: 4000, direction: ParameterDirection.Input);
                p.Add("pSearchTerm", value: searchTerm, dbType: OracleDbType.Varchar2, size: 4000, direction: ParameterDirection.Input);
                p.Add("pId", value: id, dbType: OracleDbType.Varchar2, size: 4000, direction: ParameterDirection.Input);
                p.AddCursor("pOut");

                var itemList = await conn.QueryAsync<ListItem>("SQL_PKG.ListItemGrid", param: p, commandType: CommandType.StoredProcedure);

                return itemList.AsList();
            }
        }

Where SQL_PKG.ListItemGrid returns a cursor of the same shape as the ListItem model:

using System;
using Proj.Name.Infrastructure.DataAccess;

namespace Proj.Name.Models
{
    public class ListItem
    {
        [Column("name")]
        public string name { get; set; }
        [Column("other_column")]
        public string other { get; set; }
        [Column("third_column")]
        public string third { get; set; }
        ...
    }
}

Expected: A list of ListItem with the values from our database.

[
    {
      key: "string value",
      keyTwo: "other string value",
      ...
    },
    { ... },
    { ... }
]

Actual: A list of ListItem with correct length with the keys from ListItem but null for every value.

[
    {
      key: null,
      keyTwo: null,
      ...
    },
    { ... },
    { ... }
]

Why am I getting null for all of the values?

Answer 1

After some trial and error, changing:

using System;
using Proj.Name.Infrastructure.DataAccess;

namespace Proj.Name.Models
{
    public class ListItem
    {
        [Column("name")]
        public string name { get; set; }
        [Column("other_column")]
        public string other { get; set; }
        [Column("third_column")]
        public string third { get; set; }
        ...
    }
}

to uppercase :

using System;
using Proj.Name.Infrastructure.DataAccess;

namespace Proj.Name.Models
{
    public class ListItem
    {
        [Column("NAME")]
        public string name { get; set; }
        [Column("OTHER_COLUMN")]
        public string other { get; set; }
        [Column("THIRD_COLUMN")]
        public string third { get; set; }
        ...
    }
}

Fixed my issue.

This is still confusing, as our other models/dapper calls are working and lowercase. If anyone has insight on why this is inconsistent, please let me know.

UPDATE: I did not realize that Column was provided from a function we had written and was written in a way that was not case-insensitive.

Answer 2

Let me start by quoting from this article:

The SQL:2008 and SQL-99 standards define databases to be case insensitive for identifiers unless they are quoted. Lower case characters may be used in identifiers and keywords, but are considered to be their upper case counterparts.

I see that you are using an Oracle database. Oracle complies with the above-mentioned standards. I cannot see your stored procedure definition, but if your stored procedure was defined with double-quotes around the field names, then they will be considered case-sensitive/uppercase. That could very well be the case.

So, your own solution uppercasing the columns names does make sense.