What do you do when the FRX format or the Report Designer tools aren't enough?
Think of an FRX as expressed by the REPORT FORM command not as an insufficient result format, but rather as one format among many. Your applications may need to create faxes, complex compound documents, HTML text, HLP files, along with straight reports-to-print.
Your users' expectations are high, because the component-based nature of their working environments lets them know that all these formats are simply views into their own data, that their data is malleable and shareable. VFP should give them this information in whatever packaging they prefer.
VFP is up to the task! This session will show you how to control other applications to use their format-expertise with VFP's legendary data-handling..
You need to think even more globally when you're solving output problems, however. So we'll also look organizing the reporting process on an application and enterprise level: how to catalog reports and provide access to report results, using servers and dedicated repositories.
In past conferences, I designed my Reporting sessions to show you how to go beyond the Report Writer for VFP Output, but it wasn’t enough.
It’s not enough to have techniques for extending VFP output, using new techniques and tools, if we don’t add some perspective that helps developers make choices between these options. I think we’re at the point, now, where we should be choosing between options not just because they exist, or because they are „cool“ or because we’re desperate to solve the report-requirement-du-jour. We have to start thinking more about the value of the information owned by the enterprise – how it may potentially be presented, shared, and leveraged – than about the format specified by a particular user for a particular report in a particular application.
Sure, we’re still going to have to figure out how to get dot matrix printers to print non-standard-size checks, and sure this is still a big problem for VFP. But I would like to see VFP passing the relevant data, and this problem, over to a program that can solve it easily (FoxPro DOS comes to mind!!), and getting on with its life. There are many, exciting things that VFP can do well without forcing it to do some things badly just to prove that it can do anything and everything.
Among all the exciting new techniques, I have some clear favorites and recommendations. You probably won’t be surprised to hear that many of my recommendations take the impact of the Internet into consideration.
First, let’s recap what our options used to be like, and why we wanted to transcend them, and then we’ll look at where output options are heading now.
In what I like to call „the Neanderthal era of Xbase Reporting“, the DBF and its relations were all the data you had. The character-based RW was a godsend: a real reporting engine to take care of moving through the records of a relation-driving DBF, grouping records by appropriate criteria, handling pagination, and so on. We could concentrate on calculations and formatting data elements. UDFs were a great help for both requirements, and later, with report variables, the RW gave us more focussed help on those pesky report sums and percentages.
Almost all was well with this world, and the RW within it. When the GUI-based RW came along in FP Windows and Mac 2.x, they retained these all-important engine capabilities, but their graphical environments had some additional requirements:
The 2.x Windows and Mac RWs didn’t address these three issues very well. Taking them in order:
The good news is that the VFP RW and the VFP language has given us some new capabilities and syntax with which to deal with a few of these problems when we use report forms. (I’ll cover them in my other session, which is about the Report Writer and REPORT FORM execution.)
The bad news is that they are still not up to users’ expectations in a graphical environment – and we can never expect them to meet these expectations.
Does this bad news pronounce doom? Definitely not. As you’ll see below, when you partner VFP with other Windows applications and even other data formats to create the actual output, some of the details become transparent, and even irrelevant, within VFP. Let’s look at some of the things that VFP is uniquely qualified to do within the context of output management for the enterprise.
Data warehousing, data marts, data mining, here we come. It should go without saying, but just in case you have any doubts: the significant requirements behind these three buzz-phrases are tailor-made for VFP solutions.
All three terms – which are some of the hottest fields in IS today – represent ways of providing an integrated view of data that can span multiple needs and multiple business decisions.
The distinctions and boundaries between these three buzz-phrases is often blurred. I’ve prepared a slightly tongue-in-cheek chart below to show you how mixed up their relationships get. (This is a „simplified“ chart. In reality, there are many more arrows leading off in all directions, including some that go nowhere and others that nobody has imagined yet. Do we all have it straight, now?)
We may find the verbiage confusing and sometimes laughable, but the benefits of the activities behind the terms are unmistakable, and nothing to scoff at.
Data buzz-phrase heaven, simplified (NOT!).
Warehousing may be taken to mean data merged from multiple departments and operational systems within a business, which may cover a wide variety of subjects.
Marts, by contrast, may denote more subject-oriented material. Marts either represent subsets of a warehouse or huge repositories that cover one subject in far deeper depth than the warehouse and its high-level summaries can provide.
Mining is the process by which the information in the warehouses, marts, and other data collections is examined and re-evaluated to provide new insights by business experts.
Warehouses and Marts allow quicker access to data, so that workers can find the information they need, respond rapidly to both intra-company and outer-market events, and perform repeated tasks with practiced ease. The fact that both Warehouses and Marts are assumed to be relatively static sets („snapshots“ extracted from the working databases) contributes to this rapid access, as does the summarizing formats that these collections use to bring their disparate sources together.
The summarizing formats in these collections allow business decision makers to carry out Mining activities with a focus on their business problems, not data analysis.
Whatever the exact meanings of these terms, we don’t need to struggle with them any further. The very fact that the data is at-least-once-removed from its working origins means that these repositories and extraction processes are organized with the needs of their users – not the requirements of relational theory or programmers – as a first priority.
VFP’s heterogeneous and off-line views, among many notable improvements, can be a great help in these activities. More importantly, VFP’s supple data-handling and maturing SQL syntax makes it a natural choice for applications that focus on information delivery, which is what data warehouses, marts, and mining (not to mention database programmers’ jobs) are all about.
How does reporting fit into all this? Information delivery is the art of getting data to the user in a meaningful way. Reports – or, more generally, output – are the information itself, literally delivered: accessed and accessible, visual, and visualizable. Output mechanisms therefore bear quite a significant responsibility in the Brave New VFP World.
How are we going to fulfill that critical responsibility? Clearly we can’t do so by focusing on the output mechanism, or the medium, of delivery at the expense of the precious information we handle.
Our goal should make the formatting of information as nearly transparent as possible, so that the data’s usefulness shines through the presentation. We should be prepared to jettison any technique or mechanism that threatens this process by distracting or frustrating either the developer or the user.
In the sense that the medium is powerfully able to overwhelm the message, and thus become the only message, when it gets in the onlooker’s way, Marshall McLuhan’s famous dictum is still correct, perhaps more now than ever. We all know that a CV should be printed on good quality paper with plenty of white space if we want to get a job. In the same way, if a report looks unprofessional, its contents will never be compelling to the reader.
In the Neanderthal, character-based reporting world of FoxPro DOS, many of you have heard me say that I was proud of surmounting any challenge to the RW’s capabilities, of working to make it do anything. Because of its potential to distract, frustrate, and obscure the message, I am equally proud to reject the VFP RW for any output task it can’t do professionally, easily, and efficiently. Luckily our elaborate, component-based world gives us lots of alternatives.
The limitations of the RW are not the only ones we have to confront. We have myriad frustrations caused by printer driver vagaries and other elements of the output process.
If I have one wish for you as „output developers“, it’s that you not get overly bound up in these problems. I don’t wish to minimize them. We all have clients with specific printers, and specific needs for the output from those printers, and we can work together on the workarounds required to match existing systems with our clients’ specs for output. Just make sure that these workaround solutions don’t obscure your view of the larger issue: flexible information delivery, and where that issue is going.
Our strategy should be to use native OS capabilities rather than controlling the OS with kludges, whenever possible. If another program handles the printer better than VFP, get VFP to hand the output printing job over to that program rather than trying to force VFP to print better. (I was not kidding before -- use FoxPro DOS here!)
Meanwhile, printed documents are not the only way of making documents accessible – and accessibility of data, rather than printer management, is what we are trying to provide. When you are able to demonstrate innovative ways of reaching this goal, even the most exacting clients can be surprisingly receptive, even though your solution may not arrive at its results via the implementation they originally demanded.
What kind of output should we be looking for, in our question for the best possible information delivery?
I use the words „accessible, explainable, accumulatable“ to provide some useful criteria. (OK, so the third one isn’t a word – I’ll let you and Word 97 get together and think of a usable synonym if you’ll bear with me and let me get on with my argument ;-).)
The same HTML page in four different browsers.