I’d appreciate any reasoning (pro or con) that you can provide to me on this issue. I’m working on a project where the requirements are that we extract data from a system to a flat file and then use the flat file for all our Business Objects activities. We are permitted to create a database if we wish, but the end users, who will be using Business Objects for their ad hoc reporting want to use the flat file, NOT the database. I don’t see any reason to have two sets of the same data in existence, but those who made these decisions are no longer on the project and I’m confined to the specs they created. Am I missing something very, very obvious?
Note: The data that would be in the flat file and in the database would be the same with no differences in information content.
One (major) problem with flat files we faced was: there is no control on data types. BO scans each column and decides the data type based on majority of the values. It DISCARDS values of other type. For example if you had branch codes with characters for most values and numeric for the rest, it would pick up only those rows with character values. We had to append a character for all values and later read a substring to give the original value.
Unless there is really valid reason(s), I don’t think flat files are for industrial strength reporting.
Thanks,
Krishna Malyala
Perhaps the original plan was to give your users faster response time with a flat file, vs a database containing much more than the flat file.
You might run some tests to see whether accessing the entire database creates response time problems or greater difficulty for your end users. If the results are about the same with Business Objects, you have a good case for eliminating redundancy in your work flow.
–Ray Bacon
California Department of Social Services
At 12:48 PM 11/7/00 -0800, you wrote:
Hi Listers,
I’d appreciate any reasoning (pro or con) that you can provide to me on this issue. I’m working on a project where the requirements are that we extract data from a system to a flat file and then use the flat file for all our Business Objects activities. We are permitted to create a database if we wish, but the end users, who will be using Business Objects for their ad hoc reporting want to use the flat file, NOT the database. I don’t see any reason to have two sets of the same data in existence, but those who made these decisions are no longer on the project and I’m confined to the specs they created. Am I missing something very, very obvious?
Note: The data that would be in the flat file and in the database would be the same with no differences in information content.
There is no pro reasons. You can’t easily “query” a flat file. It is possible to create an ODBC source against one, but performance is lousy. BO imports flat files. If the files are large then you will really hate doing this in BO.
My real question is this. Why are end-users given a choice in this. They don’t understand the benefits of using a database. Thinking that a flat file will give them more flexibilty is wrong.
We use a flat file for some reporting and had the same problem. You can’t change the datatypes and BO sometimes assumed datatypes that were wrong.
Our solution was to build a schema.ini file that defined the field names and data types. For example:
[codetable.txt]
ColNameHeader=False
Format=Delimited(|)
Col1=“table src id” text
Col2=“table key maj” text
This may help you define the flat file fields as the correct datatype before importing them into BO
I wouldn’t recommend using flat files for large files, but they may have a place in some reports.
One (major) problem with flat files we faced was: there is no control on data types. BO scans each column and decides the data type based on majority
of the values. It DISCARDS values of other type. For example if you had branch codes with characters for most values and numeric for the rest, it would pick up only those rows with character values. We had to append a character for all values and later read a substring to give the original value.
Unless there is really valid reason(s), I don’t think flat files are for industrial strength reporting.
Thanks,
Krishna Malyala