Hey all,

Kevin Goff helped me out a LOT with comments and sample code in another thread about LINQ queries and conversion to data tables, etc. I used his code to convert a LINQ query variable to a DataTable, but had trouble the first time since I had changed my data-generation code and was actually trying to convert something that was already a DataTable.

So, I wanted to make Kevin's original source more generic -- no reason to have it fail on something already a DataTable -- just return the table itself back. Time to make a more generic method! Here's what I ended up with (note: it doesn't compile):

    public static class VarToTable
    {
        // KEVIN GOFF CODE FROM UniversalThread!!!!!
        public delegate object[] NewRowCreateDelegate<T>(T t);
        public static DataTable ToDataTable<T>(this IEnumerable<T> qry, NewRowCreateDelegate<T> fn)
        {
            DataTable dtReturn = new DataTable();
            T TopRec = qry.ElementAt(0);
            if (TopRec is DataRow)
            {
                // If top element is already of type DataRow, then we have no need to convert types.
                // Just enumerate the qry structure and data back into return table.
                DataColumnCollection Columns = ((DataRow)TopRec).Table.Columns;
                foreach (DataColumn col in Columns)
                {
                    dtReturn.Columns.Add(col);
                }
                foreach (T dr in qry)
                {
                    dtReturn.Rows.Add(dr);
                }
            }
            else
            {
                // qry is some other enumerable that we will need to convert to DataRows...
                // Use Reflection to get types
                PropertyInfo[] oProps = ((Type)TopRec.GetType()).GetProperties();
                for (int i = 0; i < oProps.Length; i++)
                {
                    dtReturn.Columns.Add(oProps[i].Name, oProps[i].PropertyType);
                }
                foreach (T rec in qry)
                {
                    DataRow dr = dtReturn.NewRow();
                    foreach (PropertyInfo pi in oProps)
                    {
                        dr[pi.Name] = pi.GetValue(rec, null);
                    }
                    dtReturn.Rows.Add(dr);
                }
            }
            return (dtReturn);
        }
    }

Basically, I just made a second branch in Kevin's original program after testing the type of the first element.

The part that says "if (TopRec is DataRow)" works great. When my LINQ qry is already a DataTable, that first element is a DataRow, as expected, and the code inside that branch would execute (if it compiled).

Problem is, even though the branched code is within an if statement enforcing the DataRow type, nothing inside will work -- even when I try to cast T as a DataRow. The compiler absolutely refuses to let me treat TopRec as the DataRow I know that it is.

I'm stumped and frustrated. First off, I am having to write code with so many "T"s in it that it could keep a golf course equipped for a decade. I am having to abstract and abstract and abstract until I am spending all my code-writing time on abstracting the abstractions. Then, the compiler isn't even smart enough to see that my code is totally legit in the discrete blocks of code defined (the compiler sure seems smart enough to catch me doing other wrong things, so why can't it see this is "right")?

In any case, I would like to know how I am supposed to write good, global functions that can handle themselves elegantly. That's probably the biggest frustration: .NET is forcing me to make everything perfectly type safe and generic, and yet when I need the ability to write a generic, encapsulated function, I'm thwarted. Grr.

Any ideas on how to make this work? And any good pep talks to help me through these darker parts of the .NET learning curve? *smile*

Thanks,
JoeK