Question

I want to update a custom user field in QC using the Label of field instead of the name

At the moment we are doing it this way

Set currentRun = QCUtil.CurrentRun
currentRun.Field("RN_USER_03") = 1
currentRun.Post

But I would like to do it this way

Set currentRun = QCUtil.CurrentRun
currentRun.Field("Data Rows Passed") = 4
currentRun.Post

But I can’t find the method to do it with.
Any Ideas?

Answer 1

Implying all labels are unique (which I doubt..):

You could create a function which accepts a label, searches in QC’s tables that define customized fields for the correct field definition, and returns the field name. Then use the function’s result value as the indexed property’s index.

Suppose that function would be called “GetNameOfLabel”, then the Caller’s code would look like:

Set currentRun = QCUtil.CurrentRun 
currentRun.Field(GetNameOfLabel ("Data Rows Passed")) = 1 
currentRun.Post 

Of course, the function would not really be trivial, but easy enough after some digging in the QC data model and finding an efficient way to fetch the name from the DB via SQL.

Or, the function could look up the name in an array, or a dictionary, then you would have to maintain that dictionary, but you would not have to go to the database for each lookup.

Disadventages:

• Scripts with the wrong label might be harder to be debug
• If labels are not unique, it might be real “fun” to debug

If looking up on the DB:

• All scripts slow down if you don’t cache, or pre-load, SQL query results for those lookups;
• complexity, as you have to do the right SQL query, and you depend on QC’s data model in a quite peculiar way (usually a horror when you’re upgrading)

If looking up in an array, or dictionary:

• You either must maintain its initialization (bet other admin guys adding a cust field will forget that easily), or must “load” it from QC’s table (which is a bit like the SQL solution above, and has the same downsides).

I’d go with the array/dictionary-initialized-from-db-idea. Or, if you can live with the constant idea already presented, that one is a good bet. Considering that there is no session-independent scope in QCs customizing scripts, the SQL access idea might really kill performance because it would have to be executed for every new user session. Which is why I, too, +1’d the constant idea.