I am researching using MSAccess as a database for contact terms rather than purchasing a Contract Managment System. I will need canned reports and ad hoc reporting as well. Is the MSAccess reporting tool adequate or do I need to research other reporting applications to strengthen reporting capabilities?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations MikeeOK on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How strong and flexible is the reporting capability of Access?
- Thread starter cpgoomer
- Start date
Access is a very powerfull reporting tool.
It sounds like you don't know much about access, so I'll mention two other things you should know:
Develop your system as an ADP w/ MSDE. If you are starting from the ground up this is probably the better choice. This way you ustilize Microsft SQL server rather then the Access Jet DB engine.
There is also Crystal Reports. They are very popular for report generation. Worth looking into.
Mark P.
Bleh
It sounds like you don't know much about access, so I'll mention two other things you should know:
Develop your system as an ADP w/ MSDE. If you are starting from the ground up this is probably the better choice. This way you ustilize Microsft SQL server rather then the Access Jet DB engine.
There is also Crystal Reports. They are very popular for report generation. Worth looking into.
Mark P.
Bleh
Hello,
In my opinion Access itself is a fairly limited reporting tool. However, that depends on the formaat of your report. If its in excel, you can create a template and force access to generate reports in that specified format. Otherwise you might be better off with something else. If you do come across another better solution, let us all know.
Cheers!
In my opinion Access itself is a fairly limited reporting tool. However, that depends on the formaat of your report. If its in excel, you can create a template and force access to generate reports in that specified format. Otherwise you might be better off with something else. If you do come across another better solution, let us all know.
Cheers!
cpgoomer:
One thing I didn't think of: difficulties might arise when you want to create contracts from scratch. I'm not sure if Access would be the best tool for that. It's great for reporting, but to do on the fly layout & design might prove a little more demanding. Maybe some sort of xml website with a pdf writer would be better. But i don't know anything about that stuff.
but there are still postives to access for this project:
For contract management, Access with rtf features written in could create very flexible & nice looking reports.
When you are working with contract management, the idea is to include pre-filled fields, such as simple contracts for property management. You would be mailing out lease renewals with the tenant specific fields already filled in. Personally I don't think that's what Excel is used for.
With RTF & memo fields you could also have contract writer user input for contract content. This way you would develop a sophisticated report.
memkam:
what reporting tool would you suggest? Excel isn't really a reporting tool.
Mark P.
Bleh
One thing I didn't think of: difficulties might arise when you want to create contracts from scratch. I'm not sure if Access would be the best tool for that. It's great for reporting, but to do on the fly layout & design might prove a little more demanding. Maybe some sort of xml website with a pdf writer would be better. But i don't know anything about that stuff.
but there are still postives to access for this project:
For contract management, Access with rtf features written in could create very flexible & nice looking reports.
When you are working with contract management, the idea is to include pre-filled fields, such as simple contracts for property management. You would be mailing out lease renewals with the tenant specific fields already filled in. Personally I don't think that's what Excel is used for.
With RTF & memo fields you could also have contract writer user input for contract content. This way you would develop a sophisticated report.
memkam:
what reporting tool would you suggest? Excel isn't really a reporting tool.
Mark P.
Bleh
Mark,
I am a novice user, picked up Access a few months ago and I have been learning on the fly - thanks to all the ppl on this site.
I tried using Access's reporting functionality and quite honestly I felt its limitations due to the extensive data I was dealing with.
I am just reporting my output in excel. I don't know of any other way to do it. Its not a clean approach, but its an approach.
ANy input on this - PHV if you reading this what is your opinion?
I am a novice user, picked up Access a few months ago and I have been learning on the fly - thanks to all the ppl on this site.
I tried using Access's reporting functionality and quite honestly I felt its limitations due to the extensive data I was dealing with.
I am just reporting my output in excel. I don't know of any other way to do it. Its not a clean approach, but its an approach.
ANy input on this - PHV if you reading this what is your opinion?
markphsd - Gotta disagree with the MSDE/SQL Server recommendation.
MSDE/SQL Server are *sometimes* the better option. They may even *usually* be the better option. It's horses for courses though. It depends very much on what you are doing, your level of expertise, time contraints, budget........
Ed Metcalfe.
Please do not feed the trolls.....
MSDE/SQL Server are *sometimes* the better option. They may even *usually* be the better option. It's horses for courses though. It depends very much on what you are doing, your level of expertise, time contraints, budget........
Ed Metcalfe.
Please do not feed the trolls.....
In my opinion Access' reporting tool is very powerful and flexible--if the data is native, or if it's relatively simple odbc-linked queries. This is the limitation, however it is one that can be overcome.
I have used Crystal Reports, and it is a good tool. It has the advantage of the 'canned' reports ability, ie, send a person the report with the data, even though they don't have Crystal installed.
With Access, there is Snapshot Viewer, but that must be installed on the client. True, it comes with later Office versions, but it's no guarantee that the recipient will have it.
So if the 'canned' reports requirement is key, then Crystal would be a better choice.
However, if ease of development and just being able to view or print reports is the main issue, then Access, in my opinion, has a much easier interface and a more flexible reporting engine (being able to run code in report section events is a big plus--I don't believe crystal has this, but I could be wrong).
What I have done to facilitate the native data limitation is to base most reports off of pass-thru queries, so when Oracle, say, is the backend, then the joins, etc, are done on the server, and the performance of the report is excellent. When the report output is very complex, I create a table on the Oracle backend to hold the output set, then do all calculations and logic in PL/SQL, and the report is based on the final output table--no joins or criteria, just a straigt read of the table.
--Jim
I have used Crystal Reports, and it is a good tool. It has the advantage of the 'canned' reports ability, ie, send a person the report with the data, even though they don't have Crystal installed.
With Access, there is Snapshot Viewer, but that must be installed on the client. True, it comes with later Office versions, but it's no guarantee that the recipient will have it.
So if the 'canned' reports requirement is key, then Crystal would be a better choice.
However, if ease of development and just being able to view or print reports is the main issue, then Access, in my opinion, has a much easier interface and a more flexible reporting engine (being able to run code in report section events is a big plus--I don't believe crystal has this, but I could be wrong).
What I have done to facilitate the native data limitation is to base most reports off of pass-thru queries, so when Oracle, say, is the backend, then the joins, etc, are done on the server, and the performance of the report is excellent. When the report output is very complex, I create a table on the Oracle backend to hold the output set, then do all calculations and logic in PL/SQL, and the report is based on the final output table--no joins or criteria, just a straigt read of the table.
--Jim
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question