Trying to read data from CDR database and have the following file created as a csv:
The display I created only shows the last record instead of both of them and I'm not sure why.
Have the following record definition created:
NAME ENG CALLFREQ
DESC ENG "Identify potential spam callers"
NAME ENG CALLINGN
LONG_NAME ENG "CallingNumber"
HEAD ENG "Call Num"
DESC ENG "Calling Number"
TYPE STRING 50
NAME ENG FREQUENC
LONG_NAME ENG "CallFrequency"
HEAD ENG "Call Fre"
DESC ENG "Calling Frequency."
NAME ENG CONNTIME
HEAD ENG "Con Time"
DESC ENG "Time of call connection"
TYPE STRING 28
! skiplines 1
In the Extractor config I added the following line:
EXTRACT LOG (FSCOL, Solutions/CustomSolutions/Call_Frequency/CALLFREQ.ext, ..\..\..\temp/sbc_cdr_check.csv, 15,50)
I've tried this with LOG or file but with the same results. Any idea how to get all records to display instead of just the last one?
Solved! Go to Solution.
You need to assign a value to the ID_LENGTH to identify the fields used as the Key (to make each row unique). To use all fields in that row, you could set the ID_LENGTH to 80.
This is discussed in the online help under 'Defining a Record':
This represents the size in bytes of the collective set of fields that uniquely identify each record instance, that is, the 'Key' fields.
Key fields start from the field containing the START_ARRAY token and include each following field until their accumulated length matches the ID_LENGTH value. For example, a record with an ID_LENGTH of 4 has two Key fields, each one with a TYPE value of BINARY_16 (i.e. 2 bytes each).
The maximum ID_LENGTH value is 640 bytes. An ID_LENGTH of 0 is valid as this means that there are no key fields and therefore only a single row of data for the record will ever be delivered at a time.
ID_LENGTH must be an even number of bytes and must be the accumulated size of all Key fields (taken from the TYPE value of each field). For this reason, it is recommended to define the fields that are to form the key FIRST. If this value is not set to the exact total size of the fields that make up the key the following message will be displayed.
"Record ID length is not at boundary defsrec:<nnn>:<record_name>".
Where <nnn> is the line number of the record definition in error and <record_name> is the name of the affected record."
TIMESTAMP and RESPONSE_TIME fields are 12 bytes long, not 8 as you might guess from looking at their definition. See details in the DISPLAY_OPTION section of the Defining a Field topic.
In designing a unique key, it is necessary to consider that the key must continue to be unique over time. For example, at any point in time, a running process on a machine might be uniquely identified by a PID or process ID. However, over time, processes stop and start and PIDs get re-used, so a key of PID by itself is not sufficiently unique for use as the key of a Prognosis process record. A compound key of (PID, ProcessStartTime) would be a good solution.
If the key is not unique data will be lost.
Having looked at the planning phase in session one of this series, we will turn our focus to the readiness phase. The all important technical capabilities assessment, ensuring the network, endpoints and users are adequately prepared for the move.
Hear first hand from IR's Global Head of Information Systems and Technology, Jason Schwendinger, on how he has been tackling these issues.Join webinar