Does DataTable.ColumnHeadersRow Property work in PAD v2.17?

[DaveTheRPAGuy]

Have any of you been able to get the .ColumnHeadersRow Property to work that came with v2.17 (February 2022)?

I have tried the syntax like %DataTable.ColumnHeadersRow% but it always says "Property 'ColumnHeadersRow' of variable 'DataTable' couldn't be evaluated." It appears as though the Property does exist because PAD would give a different error if the property didn't exist at all or if I were spelling it wrong.

As a side note, it would appear as though the actions log file change also doesn't function. I'm actually glad this one doesn't work yet since I can find no Registry setting for v2.17 that might disable it.

As a second side note, what's the deal with the labels requirement in this forum? it shows a small list of labels, none of which apply to my post, but I had to choose one.

[MichaelAnnis]

In any “Get Data” action. There is a selector switch for telling it to recognize the first row as a header row. This may have to be enabled for this to work. Headers being in the first row would not be the same as the headers being in the actual “Header Row” where they become the column names.

Hope this helps!

 

[DaveTheRPAGuy]

Hi Michael,

Yeah, my DataTable has the headers as you describe, not in the first row. Also, the property DataTable.Columns works just fine which I would think pulls the same header information. Are you able to use the .ColumnHeadersRow property successfully?

[VJR]

Hi Dave,

I am using 2.17.xx  and below is the output for ColumnHeadersRow

Datatable coming after reading Excel (in my case has no headers, just an example)

Could there be some kind of unwanted character in the header row which is failing it to evaluate?

Try giving some meaningful headers and re-running the same to drill down the issue further.

Do share your findings.

[DaveTheRPAGuy]

The issue may have to do with DataTables created by querying SQL Server. If I read a DataTable in from Excel, the ColumnHeadersRow property works. But if I get the same DataTable from SQL Server, I get the failed to evaluate error.

I tested this to make sure by first querying SQL Server and tested using Set Variable like %QueryResult.ColumnHeadersRow%. PAD shows the QueryResult as a DataTable, but the property doesn't work. I then tested having PAD query SQL Server to get a DataTable then write that DataTable into Excel then read the same DataTable from Excel and then the property works. There must be a difference in the structure of a DataTable when it comes from Excel vs from SQL Server.

Anyone have any suggestions there? Let me know if what I'm saying doesn't make sense. I'll try to put some screenshots below.
Here's my querying SQL Server and then trying to access the ColumnHeadersRow property. This fails and gives the error I indicated earlier saying failed to evaluate.
(Edit Feb 28th: I replaced the below screenshot with a correct screenshot. Before, it showed an example of what I was doing, but it was just a bad screenshot prep that I did so this correct one shows the real code/actions with the error.)

And here's my getting data from Excel and then accessing the ColumnHeadersRow property. This succeeds. Note that the column names are exactly the same. The reason I know they are is that the Excel spreadsheet is created after querying SQL Server, so the column header row "should be" exactly the same between SQL Server and Excel. The difference is that it works when read in from Excel and not from SQL Server.

I should also mentioned I tested this on a different SQL Server database table that has no special characters such as underscores. It's purely capital and lowercase letters in the names of all the columns/fields, and it also produces the same error.

[VJR]

@DaveTheRPAGuy ,

Tried with an SQL table

You are right about the error.

You might want to submit the bug in the I Found A Bug section.

[MichaelAnnis]

Dave, in this example, it is not ExcelData, but QueryResult.  Do you need %QueryResult.ColumnHeadersRow%?  Sorry, I don't deal with SQL, yet, still learning, but just based on those 4 lines above, your SQL variable outputs to QueryResult.

[DaveTheRPAGuy · Accepted solution]

Hi Michael,

I did a bad screenshot job there. Good catch. 😃 I was copy/pasting actions in order to make the screenshot more clear since the actual actions I was using weren't on the same subflows. I've updated my reply from earlier with a corrected screenshot. I'll show here as well.

For that original screenshot (the incorrect one), if I had run it, I believe it would have given a different error anyway. It would probably have said that the ExcelData variable didn't contain a property called ColumnHeadersRow since by that point in the flow, it hadn't been assigned as a DataTable.

Here's the correct screenshot and also including the error. I've since found and also VJR confirmed it's just an issue with DataTables when they're received from SQL Server (or probably any time you do a SQL query). I'll be submitting this in the I Found A Bug section. Thanks for your help!

[MichaelAnnis]

I figured that wasn't the issue, just wanted to make sure.  In the meantime, as a workaround, if your SQL query isn't too big, maybe just launch an Excel, write it to A1, then reread it, so your DataTable works appropriately.  It is either that, or piece together a DataRow of your Header Row through something like JoinText, which might honestly take longer.

Good luck.

[VJR · Accepted solution]

To anyone who lands on this page, below is the post from @DaveTheRPAGuy reporting about the bug

https://powerusers.microsoft.com/t5/I-Found-A-Bug/PAD-v2-17-SQL-Server-QueryResult-DataTable-ColumnH...

Closing this thread.

[ThomasFonn]

The link takes me to a page with "Access Denied - You do not have sufficient privileges for this resource or its parent to perform this action."-page

Is there an alternative link?

[VJR]

Hi @ThomasFonn 

There was a 'I found a bug' link on the homepage of the forum which seems to be removed now.