Answer for:

Simple database reporting tool?

Message 5 of 8

View entire thread
0 Votes


Dr Dij

This needs to change to make it easier but that is the way it is now.

We had an end user who 'knew Crystal' but was not able to produce any reports from our system because she knew nothing about the data fields in our ERP system. She sat on this for 6 months before they gave it to me.

I was able to read in their fields database to Access and create sorts that showed me files by name, fields by name across all files, etc.

If I didn't understand where data came from I could call the vendor to find out what files, fields, but usually, by comparing to on-screen, I was able to figure it out.

You also have to work around quirks of that vendor's data. We find the same field, e.g. order number, is not populated in all fields of that name in different files.

ALso important is being able to look at keys for joins. If the target of a join does not have an index for the field you are joining on, performance of your query will basically halt if your database won't do dynamic indexes.

People also need a 'programmer's mentality' where you realize that other fields such as flags can affect data and that sometimes multiple types of data (some of which you don't want) are stored in same field, with these indicator flags.

Finally, people need the 'check it' mentality where they cross check with screens and system generated reports before making a report live. And they need to live with the quirks of the reporting tools.

Most major ERP systems have a 'metadata view' of the data for end users that simplifies, and permissions that make the view read only.

Data warehouses are the way bigger companies generally setup so that the reporting user can't change the actual data. They build in functions and commonly defined fields to make it much easier.