Referencing fields by storage location and batch number

I am attempting to access our PPM tables for a single consistent field across multiple Request types.

However, I have found that when this field was applied and always associated with column 'PARAMETER3', in a few of our request types this was inadvertently set to batch 2 rather than the default of batch 1.

How, in SQL, do I differentiate between batch 1 and batch 2 when selecting column PARAMETER3 across all request types?

  • Verified Answer


    I'm not sure I got the question right. Are you looking for the column BATCH_NUMBER in table KCRT_REQUEST_DETAILS by any chance?

  • Yeah - that's it.  I just didn't look closely enough at the table...

    Thank you.

    An additional question if you know this one - I have multiple request types in my setup.   In each one, I am able to standardize a 'desired implementation date' field to batch 2 parameter3.

    In one request type, however, I am not able to change the batch to 2 - it is defaulted to 1 and does not allow for any modification.  Do you know why a request type would restrict the admin from making this change when all of our others do not restrict it?

    If I make a new field, there as well it forces me to only batch 1 and I cannot change it to 2.

    scratching my head in confusion,


  • I just figured out the issue here now as well.  The Max Fields for this request type was set to 50.

    I jumped it up to 100 and that opened up batch 2 for me.

    I think I have what I need now - thank you for nudging me in the right direction!

  • Great to know you got things right.

    For information, it can be tedious to get data across request types when you have "similar" fields all over different parameters and batches - so one thing you may want to look into is PPM RML Schema. This will create one view per request type, and the columns will be names after field Token names - or whatever other name you decide to use when configuring RML info in the request type. 

    This should make your SQL queries much simpler to write and understand as you don't have to keep track of what field is stored where.