Using .prn file as a source

[Raj]

HI All,

How can I use .PRN file as a source for my cognos report.

what are the possible ways I can create cognos report by using .prn files as a source.

Thanks in advance!

[MFGF]

HI All,

How can I use .PRN file as a source for my cognos report.

what are the possible ways I can create cognos report by using .prn files as a source.

Thanks in advance!

Hi,

A .prn file is a set of instructions for a specific printer that describes to the printer how to render a page or set of pages. The data in it is often a mix of printer commands and binary data. There is no generic .prn format as far as I am aware - each file is specific to the make and model of printer it was created for.

All of this means there's no way I can see that .prn files can be used as a data source - in Cognos Analytics or any other BI tool I'm aware of. I think it's probably the best idea to research where the data is sourced from (the data being included in the .prn files you have), and see if either Cognos can connect to the data at source, or else see if the data can be rendered in a form that can be consumed - eg .csv or .xlsx files.

Cheers!

MF.

[Raj]

Thanks MF for the quick response.

If I render .prn file to .csv file then what is the best way to create the reports from the .csv file

1. creating the data module in the cognos analytics.(or)

2. creating datasource to connect .csv file(through odbc connector) and creating the package.

I will get source files weekly from the front end application and saving in the file directory(overriding the old file).

how can I proceed with the above requirement.

Thanks in advance!

[bus_pass_man]

The whole scheme as outlined seems to be awfully close to a gene splice of Rube Goldberg and Heath Robinson.

1.  Where is the data which is in the RPN files coming from?

I will get source files weekly from the front end application and saving in the file directory(overriding the old file).

I believe this statement is an attempt to answer MFGF's question

. I think it's probably the best idea to research where the data is sourced from (the data being included in the .prn files you have), and see if either Cognos can connect to the data at source, or else see if the data can be rendered in a form that can be consumed - eg .csv or .xlsx files.

What is this 'front end application'?

2.  Why are they in that format?
3.  Is there a less rickety method to get that data?
4.  What controls exist to ensure the integrity of the data you are getting?
5.  What controls would exist for the data in the CSVs?  How would you ensure that the data which you eventually get and then use maintains its integrity?

[MFGF]

The whole scheme as outlined seems to be awfully close to a gene splice of Rube Goldberg and Heath Robinson.

1.  Where is the data which is in the RPN files coming from?I believe this statement is an attempt to answer MFGF's question
What is this 'front end application'?

2.  Why are they in that format?
3.  Is there a less rickety method to get that data?
4.  What controls exist to ensure the integrity of the data you are getting?
5.  What controls would exist for the data in the CSVs?  How would you ensure that the data which you eventually get and then use maintains its integrity?

Just to paraphrase what bus_pass_man is saying, it sounds like the process you are describing would be less than robust, and might lead to issues.

If this is a one-off or ad-hoc thing, then adding the csv files and modelling them in a data module would be ok. There is no mechanism to automate the upload process, though, and things can get messy if the structure of a file changes.

A better approach would be to see if the data can be loaded into a database, and then add this as a data source in Cognos Analytics and model it. During the database load process you could also build in some checking and validation of the data. It would obviously require using a different tool for this - some kind of ETL or ELT tool. If the business is going to be relying on the numbers in your reports, it's a worthwhile thing to do, though.

Cheers!

MF.