Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We currently use ActiveReports (by Data Dynamics, now Grape City) for canned reports, but are considering moving up to their Reports package. If you've used it, I'd love to hear your take on:
Performance - do you feel it will scale well for a web based app (particularly compared with ActiveReports)
Export to Excel - it appears to provide a much cleaner export to Excel (ActiveReports' Excel export is awful, our biggest reason for considering a switch)
Other pros/cons (my company is pretty small, the $3,000 for 2 licenses is a lot for us)
Here are some additional information for you to consider about ActiveReports & Data Dynamics Reports:
ActiveReports Licensing:
There license is per developer. There are no royalties. You can write as many applications as you want and deploy your application to as many users or as many servers as you want without any additional costs. Read the ActiveReports License agreement here.
Reporting to Excel:
First of all, schooner is absolutely correct that all the other reporting tools have a poor scenario when exporting to excel. We recognized the same after many years of experience with ActiveReports. Frankly, it is a very hard problem to take reports designed to be paginated or deployed on the web and put them into a cell-based layout of a spreadsheet.
However, with Data Dynamics Reports', we took a completely different approach. Instead of creating just another "export to Excel", where we look at "paginated" report output and try to fit it into a spreadsheet somehow, we generate the excel output based on two things: A template and the actual data in the report.
By using a template, which is actually a specially formatted excel sheet (cells have some special place holders in them) the reporting engine can output the report's content to an excel sheet completely independent of how the report is laid out when paginated. We call this concept a "Transformation Extension" for Excel since it takes the report's content and transforms it to excel based on a template.
By default DDReports will generate a default template that you will find more often than not has pretty good output. However, if the excel output is not what you want, you can instruct DDReports to save the template so you can customize the output in excel.
The best way to get an introduction to this is to watch the screencast for the Excel Transformation Extension in Data Dynamics Reports here. Jump to about 1:20 in the screencast if you get impatient and see an example of a simple template. Keep in mind this is a very simple template and the possibilities are much more sophisticated. Unfortunately, thus far we haven't published very good documentation on using the excel transformation extension template syntax yet, but let me know if you have questions and I'll help you out! Just comment on this post or send an email to our support team.
Scott Willeke
Data Dynamics / GrapeCity
I've used it and it rocks! It has a Report Designer control that allows you users to build thier own reports on the fly and supports multiple datasources used in a single reports. Best reporting tool on the market bar none.
We use both products and they are quite different from each other. I have been a long time user of Active Reports and have loved them. But when it came time to select a .net reporting tool we did not want to spend a bunch of $$ so we decised to get their DDR product. It took me a couple of weeks to get used to it as I kept trying to use it like Active Reports. Not a good idea. Anyways, once you get used to it it does a decent job. there are some things that they need to do to improve the product. Here are the things that stand out.
You cannot access the control collection in the code area. This is a huge problem if you want to change anything like data binding inside the report.
The database connection have to be refreshed if you repopen the report int he designer. This took a while to figure out and we wondered why our fields would not show up in the preview mode when re reloaded the report.
Their new tech support is terrable. They were bought out recently and now when you call tech supprt you get someone tht has no knowledge that always tells you that someone will call you back. 80% of the time you get no call back. The otehr 20% of the time you get a sample emaild to you that has nothing to do with your issue. Now this is accorss the board with both products. THey used to have great tech support. I hope they fix this.
Those are the main problems and I know they are workign to solve the issues. Like i said we use boh DDR and Active Reports. If you need to do complicated reports stick with Active Reports. If they are simple and you do not want to spend a lto fo money then DDR works fine. I see DDR getting better with each release but it will take a while to get the knks worked out.
Just my opinion
I've only used ActiveReports as well, but their web licensing model is a bit expensive in general in my view, espeically if you need to develop multiple apps on multiple servers. Then there is the per developer costs as well.
I use DevXpress XtraReports and have been fairly happy with it so far and it has some fairly decent export functionality and a much better licensing model.
Regarding export to Excel, I've not seen any reporting tool do it well, mainly due to the formatting issues with the report itself. What we typically do is provide the formatted report to the user, along with an additional link for an Excel export which is a similar but different query with the raw data the report uses.
Another option over formatted printable reports is using grids such as Infragistics which allow you to do sorting, grouping, summaries, and which has excellent Excel export features.
This is to give more information to Bill's response in this thread. I tried to post a comment, but ran out of room :)
Bill Thanks for your honest assessment. Let me give some comments for you from the inside on the issues you mentioned:
1: Admittedly it is not quite as intuitive to access the controls collection as it was with AR, but you /can/ do it. You need to do it outside of the report (not in the script/code embedded into the report). To do it you can load the rdlx file in a ReportDefinition object. For example:
var rpt = new DataDynamics.Reports.ReportDefinition(new FileInfo("myfile...rdlx"));
var list = (DataDynamics.Reports.ReportObjectModel.List)rpt.Report.Body.ReportItems["myList"];
var txt = (DataDynamics.Reports.ReportObjectModel.TextBox)list.ReportItems["myTextBox"];
txt.Value = "=Fields!MyField.Value";
However, depending on the scenario you're after there may be a better way to handle this than changing the binding on the control/reportItem itself. It is difficult to say more without knowing more about your particular scenario/goals.
2: There was recently some discussion I was involved in on how to improve this in the very near future. The dev team was gathering use cases and doing some investigation on various caching strategies to keep hitting the database to an absolutely minimum in the designer. So look for improvements in this area in an upcoming build.
3: Unfortunately, we're working through some challenges with our new technical support team. However, we are improving constantly and we're working hard to bring up the new guys as quickly as possible. If you have a problem with one of your incidents with support feel free to email me personally with your case number and I'll work to try get your case escalated or help out in any way I can (scott dot willeke at grapecity dot com).
Thanks again for your feedback, my next letter is an internal one based on your feedback to help us improve!
Scott Willeke
Program Manager
Data Dynamics / GrapeCity inc.
I have used this product since 2004. Great performance, licensing was great. The migration from earlier versions was great. It had its flaws like ghost images for high speed high volume in production environment and missing some of the goodies you get with Crystal and bar codes issues. But this the engine was fast. Then came version 7. What a mess!! rendering a 4 x 4 label went from 320 ms to 800 ms. Try getting a patch... Good luck with that. Try getting someone on the phone suddenly became like winning lottery. If performance is not a factor and you need just simple reports, go for it. Otherwise, think twice. As for us, this is the last version if our QA can pass it. We're shopping for a replacement product.
They are good and I am not trying to frighten you, but below is the fact, in my perspective :
Pros
Active Community ... you can expect responses overnight.
Good stuff to get you started - walkr-thrus, tutorials, examples, vides etc
Internal builds - Just like Linux kernel patches you can get "hot fixe" for the problems their developer team was able to solve
Web report viewer is available and also works within Visual Studio - just like other reporting tools.
Cons
Week rendering engines - you can not expect that they are going to be exported to word/excel w/o any issues, if you use a sub-report in a table row.
Poor bug fixes - takes over a year to fix a bug - I am following one since 11-11-2011, still they keep saying "we will let you know as soon as we fix this bug"
Not too active to release stable versions. - It takes a year some times for the, to release the next stable version.
Low control over rendering, you may not use events if you wish to embed some code, but yes, Data Dynamics does provide VB.net (and just VB.net ! ) (Custom Code) support, you may use it for validation typo stuff
I am sharing some links for your reference:
forums | How to section | Walkthrough(s) | Useful resources | drill throughs | videos | Convert Crystal reports (Remember: vice versa is not possible) | online help / Documentation - User Guide | Web Report Viewer
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I need to document a MS-Access application that was created, developed and maintained completely by a power-user over 10 years.
This is an interesting situation because what they want is a manual so that a future developer can come in without prior domain knowledge and make changes to the frontend or the backend in a timely manner.
There are a few questions on my mind for this little project:
What is a good manual design creating application? Microsoft Word doesn't quite cut it.
What kind of things would you, the developer, need to know in order to make changes to things like forms, reports, tables or other Access objects?
Anything else I missed? Any pitfalls?
You could start with generating some automatic code documentation using MZ-Tools add-in for VBA. The same add-in can help you clean unused variable declarations, generate line numbers, reorder procedures within a module, etc.
Documenting forms is more difficult. My proposal would be to keep a screen shot, alltogether with a .txt file obtained through the undocumented application.saveAstext method.
In my experience, Access and VB6- based programs are plagued by more code replication and technical debt than programs in mainstream languages. I'm not sure why. Maybe it's the nature of Access as a "prototype" or "toy" database (though it can be quite powerful when yielded correctly).
If I had to choose between expending time on documentation and expending time on reducing technical debt, for example by remodularizing, eliminating repeated code, splitting long functions, etc., I would choose the latter. The improvement to maintainability and readability would be greater.
I know this is closed for long, but I can't refrain adding my 2 cents:
In the case mentionned, I think the most usefull doc to produce is a FUNCTIONAL documentation (which should have existed before starting the development in an ideal world).
Second is within the code itself, and that includes the VBA but also the field descriptions which can be set in Access and SQL Server.
Third is a (or a set of) nice database diagram.
Once you have that, all the rest can be generated by the new developer using HIS favorite tools.
Speaking about tools, I particularly like and recommend:
MZ Tools: specially to easily find which routines call the one your looking at
Smart Indent: to properly indent code. Trying to read badly indented code makes me sick
SqlSpec: (not free) generates HTML doc of the database itself for most database engines
Have you tried the using the built in database documenter? It will print out all tables, indexes, forms, controls, each property of controls. Code, the sql used and just about any thing else. This results in huge, but just massive printouts. However, while it will kill a few trees in the process it sure is a great way to impress the boss.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
How do you implement user documentation in Access? I've never bothered with formal user documentation in the past; I tend to rely on good interface design to guide users (or so I tell myself). But I'd really like to know what people smarter than me are doing...
Here are things I think I would consider important (in order):
Simplicity: it needs to be simple enough that it can be updated easily as the code changes, otherwise the documentation will end up out of sync
Screen shots: a picture's worth a thousand words; screen shots must be easily integrated into the documentation
Integration: the user can get to the relevant part of the documentation with as little effort as possible; ie, pressing F1 on a form brings up help for that form vs. opening a help file and having to navigate a table of contents
Searchable: full-text search capabilities would be nice
Other considerations:
Online vs. local: local would be faster/more reliable, but online would be always available plus search engine indexable (allowing use of google site: searches and providing some SEO benefit as well)
User Editable: how much do you allow users to make changes to the documentation: full access (ie, wiki), no access, moderated forums, etc.
Version control: text-based formats are more conducive to versioning than say, an Access table with help text inside the mdb
Exportable to PDF: seems like a nice-to-have
In Access I've never created end user documentation. No wait, I did once about 12 years ago. And I paid someone to write the manual along with screen shots. I did also have the hlp files, etc, etc. But I don't recall the details now.
Now for the Auto FE Updater, where appropriate, I have a text control which is underlned and blue which the user can then click on. The code then opens up their web browser to the appropriate page on my website using the ShellExecute API Much simpler for me than trying to figure out some kind of help system that would work for both offline and online. I also update the ToolTip control to put in the exact URL so they can see where they are going to go if they click on the text control. That's a VB 6 program but close enough for your requirements.
You may find HTML Help suitable.
I don't produce documentation for my client projects unless the client pays me big $$$ for it, as it's extremely difficult. I often guide users in producing in-house materials that document procedures and standards, but in general, I design my apps for EASE OF USE.
That is in contrast to EASE OF LEARNING.
EASE OF USE and EASE OF LEARNING often conflict with each other, as a UI design that makes it really easy to perform a task the first time often gets in the way once the user is accustomed to how things work.
However, it's important to design the UI with two things in mind:
things that are done on a daily basis don't need to be easy to learn -- they need to be really fast and friendly for the person who already knows how to use the app. I have a 10+20 rule -- 10 minutes of training and 20 minutes of use and the user will never forget how to use it.
things that are done only very seldom should be designed with a UI that is transparent and easy and doesn't require the user to remember anything at all. These kinds of tasks are great candidates for wizard-style interfaces that step the user through the process and provide hints and tips as text along the way.
I also have a number of UI design conventions that I implement throughout an app. The example that springs to mind is that any subform that is a datasheet or continuous form has a doubleclick event that when activated opens a popup form with the full details for the selected record. Once users grasp this convention, they will assume that any subform is doubleclickable in order to navigate to the detail.
There are other such conventions, but that's the basic idea, i.e., to implement similar behaviors in similar contexts so that if a user learns to do something in one context, when she finds herself in a different place with a similar UI, the things learned in the original context are transferrable in terms of basic UI behavior.
You will need to do two things:
Create a help file with topic-ID's for all of the topics
Link this help file to your access database, and link the topics
We have had very good results with http://www.helpandmanual.com/. From one single source, you can create any sort of help file that you want: pdf, online, chm, hlp, xml, ... It has a screenshot tool integrated.
Every topic can have it's own ID and you can just link your access forms / controls to this ID.
I have done a very similar thing to Tony. Its kind of a user generated content type thing let me explain.
The database contains a table with a list of the form names and then the path of a help file (word doc) that corresponds with that form.
Certain users have access to a form that allows them to say what help file corresponds to each form
Each form then has a help button so when the user clicks on it they open up the correct help file.
This way it is totally flexible, if they just want one big help file then all the links point to that but if the users want to put the effort in then they can make a file for each one. As they help files are separate from the DB storage is not a problem and also help files can be changed without having to recompile the application.
You could merge this idea with Tony’s and have the help files online if you wanted. I just find this a nice design pattern
I recently stumbled upon TiddlyWiki and have been thinking about using that as a backend to the systems Kevin and Tony described.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
EDIT : I completed this project using ABCpdf. For anyone interested, I love this product and their support is A+. Everything I listed as a 'Con' for the HTML -> PDF solution was easily doable in ABCpdf.
I've been charged with creating a data driven pdf report. After reviewing the plethora of options, I have narrowed it down to 2. I need you all to to help me decide, or offer alternatives I haven't considered. Here are the requirements:
100% Data driven
Eventually PDF (a stop in HTML is fine, so long as it is converted)
Can be run with multiple sets of data (the layout is always the same, the data is variable)
Contains normal analysis-style copy (saved in DB with html markup)
Contains tables (data for tables is generated at run-time)
Header/Page # on each page
Table of Contents
.NET (VB or C#)
Done quickly
Now, because of the fact that the report is going to be generated with multiple sets of data, I don't think a stamped pdf template will work since I won't know how long or how many pages a certain piece of the report could require.
So, I think my best options are:
Programmatic creation using an iText-like solution.
Generate in HTML and convert to PDF using a third-party application (ABCPdf is the tool I have played with so far)
Both solutions have their pro's and con's.
Programmatic solution:
Pros:
Flexible
Easy page numbering/page header/table of contents
Free
Cons:
Time consuming (to write a layer on top of iText to do what I need and keep maintainable)
Since the copy is already stored in the db with html markup, I would have to parse through the data before I place it into the pdf, ensuring I don't have to break the paragraph into chunks so I can apply bold, italic, underline, etc. to specific phrases. This seems like a huge PITA, and I hope I am wrong about that assumption.
HTML -> PDF
Pros:
Easy to generate from db (no parsing necessary)
Many tools for conversion
Uses technology I am already familiar with
Built-in "Print Preview" - not a req, but nice
Cons:
(Edited after project completion. All of my assumptions were incorrect and ABCpdf is awesome)
1. Almost impossible to generate page headers - Not True
2. Very difficult to generate page numbers Not True
3. Nearly impossible to generate table of contents Not True
4. (Cross-browser support isn't a con; Since its internal, I can dictate what browser to use)
5. Conversion tool quirks - may not convert exactly as rendered in browser Not True
6. Overall, I think it would be very hard to format the HTML exactly as I would want it to appear/convert to PDF. Not True
That's it - I need the communitys help in deciding which way I should go. I might be wrong about some of my Pro/Con assumptions. If I am, please tell me. All thoughts and suggestions are welcome and appreciated.
Thanks
Decided on using an approach similar to the one used at
http://alistapart.com/articles/boom
Using ABCPdf instead of Prince for the eventual HTML -> PDF generation.
Anyone who is interested in the same thing, feel free to message me about this approach.
I think that if you have a full version of Adobe Acrobat Pro, it comes with Adobe Live Cycle. You should be able to produce reports generated from a database from it. It will give you everything you need in formatting since you will create the report from scratch.
You can create a database connection to an OLE database that will feed data to your form fields. You select the tables to be used, any stored procedures that will run, any queries, and then the data will appear on one of the pallettes in the designer.
You can also use Web Services (WDSL) to receive and process commands and return the results to the form.
Either way, you would bind fields to your data source and then the data would be displayed in your form.
If you're willing to do a little .NET work there's this:
http://www.dotnetvj.com/2009/05/populating-pdf-from-aspnet-using.html
Depending on which platform you are using and targeting, you might want to consider a reporting solution. These are not perfect but the one thing they do give you is the ability to write a report once and then render it in HTML, PDF, or even Excel.
Usually they also provide an editor that helps you design the report and make it look just right. They provide things like paging, headers, footers, graphs, etc. They also provide an API that you can use to programatically create and run the reports.
I've used Reporting Services in a MS environment and Jasper Reports in a Java environment with good results in both. I'm sure there are other options but these are the ones I've been able to use successfully.
For the HTML→PDF step, I really love Prince. It looks like you can call it from VB.
My recommendation is to use SQL Reporting Services.
Can design every page & table of your report
Include Header and Footer
Include Page Numbers
Table of Contents
Can span through multiple pages
Supports Images & Charts
Can be rendered to PDF without a need for any thrid party PDF Converters
I'm a 80% ruby on rails developer, but still need to do some Access VBA work.
Some of them are very shit systems, been build ages ago , used by the big enterprise globally , so that most of the works are just enhance the old system.
The techniques are basically MS Access as front-end, linked-table which link to SQL server via ODBC as back end.
Now, I really think I need help , just want to know is there anybody can build the elegant VBA application follow the object-oriented patten?
Even better if you can show me a snippet of code to demonstrate how good it can be, thanks.
Well the first issue to keep in mind is that there’s no magical shortcut to learning MS access. Over the years I’ve learned a lot of development platforms ranging from mainframe systems, databae systems, all the way down to hand coded assembler on a PC. I written two payroll systems from scratch (with the revenue Canada formulas for taxes included in those systems). One system was from scratch written Pascal where I even wrote my own data engine.
Make no mistake, ms-access is a complex developmet system.
You can build gorgeous looking drop dead applications in access. take a look at these screen shots:
http://www.fairsoftware.com/screenshots.aspx
Note the cool ribbons in the above screen shots.
The problem is you can’t learn Unix in a day, and you can’t learn Oracle in a day. You also can’t learn MS access in a day. If those applications you been given to maintain are complex, then hiring a developer with 4-5 years of experience is what you need here. The idea that somehow you going to get up to speed in ms-access faster then say vb.net, or c# is really a false concept here.
In fact I would go so far as to say that you can Learn Oracle quicker than you can learn MS access. While the learning curve in MS access is not so steep, it is very long.
VB6 is a walk in the park compared to access. VB6 forms are dead simple, but the forms in access are very complex (we have about 3 times the number of events and properties for the given form). For example, in access we have two events that fire when an form loads (on-open, and on-load). VB6 forms (and even .net forms) only have one event. The on-open event has a cancel option. If you set cancel = true then the form will not load and will not be displayed.
Logically, this means that the form has two distinct events for two distinct purposes when you call the form. The on-open event will thus have code used for verification and testing of certain conditions of data (and allow you to cancel). If the on-open event is not canceled, then the on-load event then fires and the form loads.
Logically, at this point this means that code that sets up variables or initial values of controls on the form needs to be placed in the on-load event ( in fact Controls cannot be modified but only examined in the on open event). So there’s a very nice granularity and distinction between the two processes that occur in a typical form load. It’s also interesting to note that most products in the marketplace don’t have these two separate events.
As a developer, thus you place the appropriate code and use the correct event for a given purpose. It will take some experience in having used access to figure out which event to use for these things. You could ask if there’s a book that explains this problem, but that’s like asking is there a book that tells you when to use a combo box over that of a list box? I don’t think there is such a book.
The documentation for a combo box will explain what a combo box is, and how to use it. The same goes for the documentation access has for the on open event. You can read what on-open does, but then you as a developer will have to figure out when it’s appropriate to use that event. The same goes for when it’s appropriate use a combo box or that of a list box. At the end of the day, the only solution and how to know these issues is going to be your experience as a developer with the product.
I have an article that talks about using class objects in MS access, and when to use them here:
http://www.members.shaw.ca/AlbertKallal/Articles/WhyClass.html
If you’re looking for code samples from everything to forms to reports to using windows API, a great reference is here:
http://www.mvps.org/access/
You have my sympathy - Access VBA is not object-oriented in any sense like Ruby. You will have to change your mindset when tackling development in Access; such applications are almost always geared around the concept of data rows and sets rather than objects. The user interface is often bound to data rows and sets in a way that hides a lot of plumbing.
Having said that it is possible to build pefectly decent maintainable applications in Access with care and attention. Good luck.
One thing that just futzing around in Access won't teach you is how to create and use standalone class modules. These have some aspects of object orientation, but not a whole lot, but they can be extremely useful in making your code more manageable, as you can wrap a lot of operations in a standalone class module and then treat it as an object that can have multiple instances. You don't get inheritance and polymorphism and a lot of the other buzzwords that go with the OO gospel, but it's worth taking a look at what they can do if you've never used them extensively.
This article is old but make a great case for considering Access as part of the enterprises long-term application strategy.
http://www.fmsinc.com/MicrosoftAccess/Strategy/index.asp
Seth
Take a look at the Implements statement i.e. polymorphism via interfaces. That's about as OO as VBA gets.
http://www.huagati.com/dbmltools/
I've been using the Huagati DBML tools for a project for the past five months or so, and just the "Update Linq-to-SQL Diagram from Database" function is worth the registration price. I haven't run into any compatibility problems, but that's the only 3rd-party add-in for VS2008 that I'm using, so not sure about how it plays with ReSharper.
It still boggles my mind that Microsoft released the Linq-to-sql designer (for .dbml files) without an "update diagram" feature built into it, but the Huagati plug-in does that, plus some other niceties (you can specify how you want to 'prettify' your column-name/properties, so that all my Tablename_Id columns become TablenameID properties. I did have to add a couple lines to the list of fields marked "auto-generated" (by default, my bit columns that default to 0 or 1 weren't marked as auto-generated, even though they are). A nitpicky complaint is that you can't type in the box that has the list of auto-gen values (you can't hit 'enter' to create a new line - so you have to copy/paste from notepad).
Other than that very, very minor nitpick though, the DBML tools have saved me a ton of time. I also like the "compare" feature to see what's out of whack before I go and actually commit to changing my Linq classes (also useful for comparing the dev linq ORM classes to a production database, in case you forget to document changes to the dev DB as you go...)
So anyway - after more than 5 months, I give it a thumbs up.
Kirk
If you've moved to Entity Framework this is clearly a tool you should know about. I've been disappointed by the EF designer's "Update Model From Database..." feature and I'm blown away by the simplicity and power of Huagati's Model Comparer tool. The Model Comparer for EFv4 shows differences between the database, SSDL, and CSDL layers and allows individual differences from one layer to be synchronized with another or left in place. I've just watched the demo video and I'm highly impressed. I wouldn't be surprised to see this sort of tool included in the next version of Visual Studio. Unfortunately I can't give hands on feedback yet, just a heads-up.
If you send an email to support#huagati.com I can put you in touch with some existing users. (Assuming you want to ask other users about their experiences..?)
Or if you have any specific questions on how to use it, please be more specific.
Also, (in case you haven't visited it), the support forum is a good place to get hold of other users and to ask specific questions about the tool... You can of course also email any questions you may have to support#huagati.com
http://forum.huagati.com/forum1-huagati-dbmledmx-tools-support.aspx