Wednesday, June 25
by Hans-Otto Lochmann and by Jan Vit
How to Use an OLAP from Visual FoxPro by Miroslav Krejcí
Data warehousing has emerged as a distinct discipline in the database design. The purpose of this session was to try to help the Visual FoxPro developers to understand the fundamentals of data warehousing and to get an idea, when and where this technology might be applicable. Also this session gave some ideas to a Visual FoxPro developer what to consider when a user wants to interrogate a database with varying queries and different evaluations.
Relational database usage falls primarily into two main categories: on-line transaction processing systems (OLTP) and on-line analytical systems (OLAP). Both approaches to database design are equally sound from a theoretical construct point of view. Thus your selection of one or the other design should be determined by the functional requirements of the system.
Transaction processing systems are used both to record and view information in real-time. Such systems are typically optimized for supporting a specific set of business processes. Although historical data is available in such systems, the main design goal is to support the needs of the people who run the daily operations.
If the data of a company has to be queried over a longer period of time, say 5 years, for example to make a marketing analysis, then the importance of the speed of transaction processing diminishes drastically behind such question as to which timeframe some data belong, how they are interrelated to each other and so on. Hopefully the company has not changed its organization, its line of products, its markets, etc. in the last five years... otherwise the implications on the data has to be taken into consideration as well.
The heart of the data warehouse is the "dimensional" schema: a central fact table surrounded by "dimension tables" and "transform tables". The fact table depicts for instance the business process to be measured. The dimension tables will contain the selections and their attributes, which will be used to constrain the records in the fact table, as well as provide the values used for grouping and sorting the results. This dimensional schema is also known as star, snowflake or cube, because it is often visualized using these schemes.
As the difference between OLTP and OLAP is the design (an of course the usage it is designed for), any good tool with which an OLTP design can be implemented can also be used to implement an OLAP design. Miroslav showed how to do it with Visual FoxPro.
Steps for creating a data cube:
- consider what data does the user want - what dimensions do we need to have
- find the sources of the required data
- put all these information into the OLAP with help of the builder
- define the access rights
The only thing that must be done at the frontier is just to add some control for showing the data.
Miroslav then showed how easy it is to put the OLAP browser to the VFP form.
Application Security under the .NET Framework by Michael Jurek
In the past time, there were always two security difficulties with fat applications:
Applications were giving a big chunk of "trust" to the users. This was the main reason why
- things like the "I love you" virus spread so quickly
- Applications couldn't properly give the rights to the program's code
This session discussed the trustworthy computing, maintaining the code security, code access security (CAS), role-based security and cryptographic services.
At the end Michael again repeated that .NET Framework is ready for all the security issues, which are in use at these days, but without a good code, good administration and trained users, the security will never be anything.
XML Adapter and XML Web Services by Ken Levy
As usual with a "pure Ken Levy lecturing session" there were not bells and whistles, eh, Slides and Videos. He just started FoxPro and off he went.
Ken first concentrated on explaining the nature of a XML: An XML is not a data storage vehicle, but a mean to transport data. Of course, if an XML string is used to transport data, it does contain data, but this "data container" is of a fragile nature. Permanent data storage should be done in SQL Server or - of course in tables of our beloved FoxPro.
The data in XML strings have to be organized somehow. This leads us to the "definition" of XML. That expression stands for eXtensible Markup Language. It provides a mean to describe data and its structure. It is internationally standardized by the W3C workgroups.
The real strength of XML is, that it kept its definitions on a highly abstract level. This is achieved by separating the syntax from the semantics. XML only specifies the syntax. Semantics by the way denoted the meaning on a word or any kind of data. XML provides also means to describe the semantic of a string of data, to define the nature of the data elements, to define the structure of the data and so forth. Two items were stressed by Ken especially:
The DOM (Document Object Model) is a defined standard for programmatically accessing the structure and data contained in an XML document. It is based on an in-memory tree representation of the XML document. When an XML file is loaded into the processor, it must build an in-memory tree that correctly represents the document. The DOM also defines the programmatic interface (including the names of the methods and properties) that should be used to programmatically traverse an XML tree and manipulate the elements, values, and attributes.
A schema is basically a set of predefined rules that describe a given class of XML document. A schema defines the elements that can appear within a given XML document, along with the attributes that can be associated with a given element. It also defines structural information about the XML document, such as which elements are child elements of others, the sequence in which the child elements can appear, and the number of child elements. It can define whether an element is empty or can include text as well as default values for attributes. Document Type Definitions (DTDs) and XML-Data are both examples of specifications that outline how to describe XML document schemas.
Because XML is truly about interoperability and everyone is free to create their own XML vocabularies, everything would start to break down rather quickly if different developers chose identical element names to represent conceptually distinct entities. To safeguard against these potential conflicts, the concept of "namespaces" were introduced into the XML language. It provides a "space" in which a developer can use "his/her" name conventions, as he/she likes to do and being safe not to create any potential ambiguities.
Microsoft provides a set of standard COM interfaces in its XML parser (Msxml.dll), which can easily be invoked in FoxPro using the Create Object() function. Ken spent considerable time using an instance of this XML parser to demonstrate the various features of XML and the XML DOM. He also explained why it is necessary to set the property async of this instance to False and on this feature he explained the "inner working" of data transport via XML.
Finally Ken showed the use of FoxPro to generate and to consume XML data streams, which - invariably - resulted in "How to use Web Services".
There is a great wealth of information available on XML in various places in the internet, e.g. in MSDN.
What are Collections and how to use them in Visual FoxPro 8.0 by Hana Horová
This session discussed this new feature of Visual FoxPro collection in depth.
At the beginning of the session Hana reminded the audience, that collections are nothing new at all. We all are using them when we are writing applications, which incorporate Word or Excel automation. The Property “Columns” in the grid control is in fact a collection or Objects in Form, an OptionGroup and other container. And we were using them even in earlier versions of VFP.
But these collections came with the container, but there was no separate base class collection. Now this has changed: The new collection class in VFP 8 allows you to create your own collections.
Hana demonstrated the use of all the important PEMs, such as the Add, Remove or GetKey methods. With appropriate examples Hana showed the usage of this new class and explained the rules which FoxPro uses to assign the indexes to the collection's fields.
At the end she summarized that collections can be used as improved object arrays and that we all should start to use them.
Distributed Applications over the Web with XML by Rick Strahl
Rick devoted this session to lecture his audience how to find out how to share content between Web Servers and Fat Client VFP applications by utilizing the HTTP protocol and HTTP to shuttle data between the client and server.
Rick first explains what he defines to be a distributed application:
- A smart client, which runs code or script and makes requests on server for data or logic.
- A fat server, which provides business logic and data and runs standard Web backend software.
- The communication between both goes over the Web using HTTP and XML.
Rick then explains carefully each item in his list to give an overview of how distributed applications work. Rick then describes 3 different approaches how this technology can be applied. These approaches include
- Web/XML Service Wrapper Classes
- Web Data Access
- Object Marshalling
As ever, the explanations are illustrated by examples, which are freeware. Just examine Rick's Internet Site to learn more.
Why You need a good Injury Insurance when Moving from VFP to .NET by Petr Hojný
This session was all about what an expert VFP developer has to consider when migrating from VFP to the Visual Studio .NET.
In the center of this session there was an application, which comprised of only one form and some data. Petr explained this little application and then showed how the code would look like if it would be written in Visual FoxPro.
Everybody in the audience agreed, that an expert developer could write this in 15 minutes.
Petr then opened the Visual Studio .NET with a form looking exactly the same as the VFP form. But then there was no code in it! Then, for the rest of the session, he tried to implement all the functionality of the original VFP application to it. He did it very carefully, so everybody in the audience could get a really good understanding of the different way of thinking when developing in VFP or in .NET.
Petr did not recommend do not use .NET, his point was to demonstrate that that what looks easy might not be easy. So think carefully, what you are going to do whenever you leave the ground well known to you, and prepare for all the risks you might encounter.
Using FoxPro for building W@P applications by Petr Bauer
Some of us probably already tried to build some WEB pages. If you haven't or if you are bored with building ordinary WEB pages and if you really would like to try something absolutely new then this the session would have been the right one for you.
Petr directed the session to tell the audience how to use FoxPro for building W@P applications.
He explained the necessary basics of WML (Wireless Markup Language), demonstrated how to create forms and how to create links in WML. Then he also briefly discussed the structure of the WML file and demonstrated the configuration of the server and VFP.
This session gave the listeners a very good idea, how easy it is to create W@P applications with use of Visual FoxPro for the mobile phones if you dare to try it.
Getting The Most Out Of Your Visual FoxPro MetaData Source Files by Drew Speedie
Drew Speedie, a well-known speaker on many DevCons, uses Visual FoxPro since its version 3.0. At this stage Visual FoxPro already had many features and tools, which made it a superior application generation system just from its beginning.
If you know Drew then you will easily understand, that he quickly found out, that quite a few things could not be done as fast as he would like to do them. So he started to look for shortcuts.
FoxPro has always stored a large percentage of source code in meta data files like .SCXs, .VCXs, .FRXs, .LBXs etc. There is no magic involved in getting that information into the appropriate Designer; everything you see in the Form and Class Designers comes directly from these Meta Data files.
These Meta Data files are just VFP tables with a special extension. Also the structure of these tables had always been well published in the Help files. So once you know your way around these files, many tasks that are either time-consuming or impossible in the VFP IDE can be accomplished efficiently and quickly. You even can automate tedious maintenance chores if you know how to update those files programmatically.
In this session Drew firstly showed the basics in hacking these .SCX and .VCX files. He gave convincing demonstrations of several techniques you will find indispensable once you know how to use them.
But Drew stressed one caution measure in the beginning: AS all the methods, which he was going to demonstrate will irrevocably change these files, you should make a backup copy first!
Drew demonstrated how to modify objects without using the Designers. This included tasks like:
- redefine the class on which a form or class is based;
- retrieve lost method code and recover other deleted PEMs;
- manipulate the properties of 'leaf' controls;
- redefine members of a form or class;
- redefine members on initial form creation;
- re-sort classes alphabetically;
- re-sort class methods for better arrangement in the VFP 7.0 Document View window;
- specify the initial method on Dbl-Clicking the object surface;
- rearrange the order of columns, pages;
- cleanup pathing problems in the ClassLoc field;
- merge two classes into one class;
- runtime hack of SCX, .PRG, .EXE;
Finally he showed how to extend the VFP 7.0 EDITSOURCE() function, which in his opinion is well conceived, but its realization is just 2 % too short. Maybe that this enhancement will be included in Europa.
The History of Relational Databases - Jaroslav Pokorný
This session gave an overview of the SQL and Relational Databases Technologies.
The handling of redundant data was the problem, which was solved by the Relational Database Theory. In 1970 Dr. E. F. Codd published a paper entitled “A Relational Model of Data for Large Shared Data Banks”. In that paper, Dr. Codd introduced a set of rules intended to eliminate the need to store redundant data und thus introduced the world to the Relational Database Theory.
The paper of Dr. Codd not only set rules for storing the data, it also defined rules on how to retrieve data. When IBM developed their first system to realize Relational Databases (1974 System/R) these retrieval rules were cast into a formal language, which, because it used English command word, originally was called Structured English Query Language (SEQUEL). The name was later (1981) shortened to Structured Query Language (SQL).
Just to give the audience an intuitive feeling what this is all about Jaroslav then explained how the inner working of a Relational Database could be envisioned using an everyday situation in a rather drastic example. Let's cite him literally: “Relational database would be thought to be very similar to a garage which would force you to disassemble your car to the smallest parts before you can park it inside.”
Though IBM's SQL had quite a few competitors, the sheer weight of the company made it a de facto standard, which - after everybody got used to it - resulted in "real" standardization. Some important dates:
- 1986 - SQL 86 - first ANSI standardization
- 1987 - ISO 87 - accepted by ISO, Data Definition Language (DDL)
- 1992 - SQL 92 - new data types (= extension of the DDL), new connection types
- 1998 - SQLJ - Java
- 1999 - SQL:1999 - becoming object oriented
- >2000 till today's SQLs - SQL4
s
Jaroslav then also pointed out some possible problems, which may occur when using these technologies and put emphasis on the fact that many of the technologies he mentioned are still in the development and thus not yet perfect.
The resulting relational model is a data model that represents data in the form of relations. A data model is a conceptual collection of the data, relationships, and constraints on the data. Therefore, it follows that the relational data model is a conceptual representation of the objects, events, and associations in a relational database system. What all that really means is that the relational data model requires that data be stored in relations.
A relation is represented by a table that stores information about an entity—a conceptual collection of one type of data. Each row corresponds to one tuple and a column corresponds to an attribute. In this context, an attribute is simply a named column in a relation. Each attribute is associated with a domain (i.e., the possible set of values for that attribute). For example, Table A lists the domains for a few attributes of a relation that stores data about books.
How FoxPro Works Internally by Christof Lange
The material, Christof was going to present in the session, is fascinating and difficult. At the same time is it essential for each developer to have at least a sound basic understanding of how FoxPro works internally.
Being a FoxPro developer by convinction does Christof nor prevent from stating: "Visual FoxPro is a lot: it's fast, productive, stable, amazing, surprising... but it certainly isn't logical and consistent." Christof showed that almost two decades of development with three fundamentally different programming concepts, with four operating systems and two different compilers left their traces in a product everybody in the audience and in the DevCon loves to employ and use. As Christof outlined, FoxPro is a high-level development tool. When someone wants to use it he/she can
do so with ease and is not required to have a good knowledge of its internal working. It is - at leas in this respect - much easier to use than VB or .NET. But, as he outlined, it's quite helpful to know what is going on behind the scenes in order to have a good perception of what could have gone wrong if problems are encountered.
Christof then lectured on these topics:
- the internal management of variables,
- memory management,
- handling of classes, objects and containers (and why those are the same, yet completely different),
- the content of the system data session,
- the impact of cache, buffers and transactions,
just to name only a few.
There is not enough space here to dig any deeper into these topics, because each of them requires a careful description of the underlying process or design feature. But Christof has written an excellent paper on this subject, unfortunately it only available in German (D-HALT.doc), but you should check his account in the German FoxPro user group, perhaps he will publish this in English.
There in one thing, which Christof made very clear, just from the beginning: The actual internals of FoxPro are the intellectual property of Microsoft and are not publicly disclosed. Everyone who really knows how Visual FoxPro works inside is prohibited to talk about this by signing a Non-Disclosure Agreement (NDA). Therefore Christof had to use public available sources, experiences from other developers and his own experience
gained when using FoxPro. But all of this did not prevent him from presenting a clear picture of the internal operations of FoxPro at least as it was needed to follow his ideas and statements,
Transactions in Visual FoxPro and SQL Server by Milan Kosina
The goal of this session was to highlight, that transactions are one of the most important data features in Visual FoxPro and SQL Server.
Basic feature of transaction can easily be remembered by the code ACID
- Atomicity: either all action are done or none at all
- Consistency: the data must remain the same
- Isolation: no one should be able to see only some data of the set - either none or all
- Durability: once the changes are committed they cannot be revoked
After that Milan outlined the basic rules for using the transactions in applications:
- Transactions can be used only on a table that belongs to the database
- The table header is closed during the transaction (nobody can add new records at that time)
- The highest level of nesting is 5 times
- SET MULTILOCKS must be set to ON
Then Milan showed, how transactions are implemented into Visual FoxPro
- Atomicity: is provided by the way transactions have been implemented.
- Consistency: TABLEUPDATE() will return .F. if the integrity is violated or the data could not saved in one or more tables involved in the transaction for whatever reasons.
- Isolation: VFP will lock the rows when it starts the transaction processing. During this time only then data ("old" data) can be seen by other users, which have been in the tables when the transaction started. Only if the transaction is "successful" (i.e. all changes can be committed), then this "change committing" will really happen, and the other users then will "see" the changed data.
- Durability: is not implemented in such a way as Milan thinks it should have been.
The session then continued with lots of code examples showing how to effectively use the VFP or SQL transactions.
What You Should Do For Not Getting Into Trouble by Darina Vondrážková
Attendees who don't want to break the law benefited from this session the most.
The session explained, what the EULA and the software assurance is, how does the upgrade and downgrade work, how to make licenses for your own applications and so forth.
After leaving the session everyone was able to answer the most frequent questions about licensing, such
as:
- How can I prove the legal license?
- How many licenses do I need when working at home and in the office?
- Which software can be propagated and which cannot?
- How many people can share one license?
- What is the OEM (Original Equipment Manufacturer) license and what is so special about it?
This session definitely cut the software piracy in The Czech Republic to the world's minimum.
Visual FoxPro Tips and Tricks by Drew Speedie.
In this session, Drew presented a great variety of tips and tricks. Obviously he has been busy collecting these techniques, because he would rather run out of time than running of tips and tricks.
The items covered a broad spectrum of VFP development, from improving productivity to managing classes to working around VFP limitations and anomalies. These tips and tricks are of rather close to everyday application development experiences so that the audience should be able to put most of these techniques to work right away.
Drew has prepared a Visual FoxPro application, which includes all these techniques. When each of these tips and tricks is called in the application window, then the application "unpacks" the necessary code (if any exists) into the directory this application is located in, so this code can immediately be tested and - if found useful - it can be copied/pasted wherever you want it to be.
The examples, tips and tricks can mostly be used in all versions starting with Visual FoxPro 6 or bigger, a few only apply to Visual FoxPro 8.0 only.
So much for today!
Thursday, June 26
by Hans-Otto Lochmann and by Jan Vit
Active FoxPro Pages 3.0 by Jürgen Wondzinski and Christof Lange
This was by far the best session of this morning (mostly due to the lack of competing sessions - sorry for that, wOOdy and Christof, but we just could not resist...)
wOOdy, as he is known by all the insiders, presented this session in his usual manner: relaxed and concentrated to topics, congenially supported by Christof, also well known, among others from the FoxPro Advisor Magazine QßA section. So it was as well fun for the attendees to watch them handing the baton to each other flawlessly as it was a "e;serious seminar"e; with some very important lectures to learn and to use immediately.
Basically this session was a vendor session and a lecture session at the same time, both well done.
wOOdy and Christof firstly gave a brief overview of the history of Active FoxPro Pages (AFP) and explained its basic principles. AFP "connects" Visual FoxPro to web.
AFP is an internet server extension that processes program code inside an HTML page, like Microsoft's ASP technology. But AFP is also a script engine for FoxPro code that let's you dynamically present your data on the Internet. But since it does not require ODBC or ADO to access to your data AFP much faster. wOOdy and Christof's claim, that AFP might be by far the fastest system of this type, at least as far as data access
is concerned. But this claim has not been challenged yet. Of course this confidence is based on the fact, that AFP is based on the world's fastest Database system: Visual FoxPro.
AFP features a built-in programming language with more than 400 commands and functions for any and all application purposes. It also provides for using most of VFP commands and functions in web programming. Most important: it comes with a framework, which in its design follows the design principles on which Visual FoxPro is build. Therefore the learning curve is dramatically reduced: A single-day jumpstart into AFP Framework is all you need to open your personal access into web development in your favourite FoxPro environment - at least that is what wOOdy and Christof maintain.
Also the AFP Framework designed as a Rapid Application Development tool for easy and fast development of web applications on Visual FoxPro platform. AFP Framework claims to be a powerful and productive tool. Among its features
- AFP Framework is project-oriented. Inside the AFP Framework you can develop and maintain many independent web projects. All projects are separated in own directory structure (under c:\inetpub\wwwroot\) and have own dataset.
- Every project has a data dictionary with definitions of project databases, tables, views, fields, formats and many other properties.
- Based on a data dictionary, the AFP Framework knows how to generate many types of web forms and even web grids.
- AFP Framework comes with WebObjects, which can be customized to a great level.
- Skins are not only available on mp3 player right now anymore: Every WebObject can be generated in one
of 12 predefined application visual skins. So you can totally change the look of your web application in a few minutes. And you can give this power to the user as well!
- "Free" web pages usually have to be provided additionally in web applications besides the "data based" based just on plain text. All this can easily be done with the "FreeWebPage designer" - which is a real visual WYSIWYG html designer and web page generator inside the AFP Framework.
Building Applications with Visual MaxFrame Professional by Drew Speedie
This session was announced as a vendor session, but as with wOOdy's and Cristofs session, it was a great lecture as well.
Drew introduced Visual MaxFrame Professional (VMP). It is an object-oriented application development framework designed for Visual FoxPro and has the following features:
- VMP consists of a set of class definitions in .VCX visual class libraries and procedural code libraries for use in creating an integrated set of application components providing basic features common to most Visual FoxPro applications.
- VMP is intended for use by Visual FoxPro developers who have not yet developed their own applica-tion framework and want to take advantage of the features in Visual MaxFrame Professional.
- VMP is not an "application generator" – it cannot be used to automatically create data-entry forms based on a data dictionary, etc. VMP is an application framework – the framework classes can be subclassed into the developers own customized framework objects.
- VMP is not "pure OOP" - where appropriate, native VFP constructs will be used, procedural or other-wise to solve problems with the best available tool.
- VMP allows you to develop applications using any of the following architectures:
- 1-Tier (VFP code, VFP database)
- 2-Tier (VFP code, remote database)
- n-Tier (any presentation tier including a VMP desktop application, VMP business objects in the mid-dle tier, any database)
- In fact, VMP even supports mixing any combination of the above architectures in a single application.
- VMP has been designed with the average FoxPro developer in mind. We use VMP to develop Visual FoxPro applications, mostly mid-to-large business applications requiring a team of developers. Visual MaxFrame Professional is the tool we use to shorten the learning curve and get the team as productive as possible as soon as possible.
After having stated this, Drew then demonstrated the various features with well-suited examples. And to learn from these examples has been an adequate End of the DevCon
Other events and sessions of Thursday.
There were more session on the morning of this day, but these were repeat sessions. So there is no need to report about them.
The DevCon ended at lunchtime and everybody went home.
Thank you for reading so far!
Closing Words and Acknowledgements.
This has been the report about this year's DevCon in Prague. Including speakers more than 480 people attended this DevCon (485 to be exact). Excluding the speakers most of the attendees came from the Czech Republic, but there was a strong minority of people from 11 countries, one attendee even came from Israel.
If you look onto the trends of the recent years then as many people have attended this 6th DevCon as in the years before. This is in so far remarkable as the population of the Czech Republic is about 10 million people. And of course this rises the question, why this is so.
Well, let me, Hans-Otto Lochmann, tell you some of my ideas why this might be so. First of all this event is not just a Congress of Developers, it is also a kind of a family reunion. Attending this DevCon is somehow connected with some kind of a "coming home" feeling.
Then there is the location. It "only" takes place in one of the buildings of the Faculty of Electrical Engineering of the Czech Technical University (CTU). Though the DevCon always takes place when there are no lectures, that does not mean that life at the Faculty of Electrical Engineering had died out: Students come and go as well as professors and other people working in these buildings. The buildings themselves are as those buildings that you find in universities: rather functional, unemotional. There are message boards, covered with news to the students, but there are also instructional posters, explaining for instance, how the various protocols of the Internet are interrelated and other useful things.
I do not know, whether this really is important, but the atmosphere at CTU is very sober. Exactly the one you would expect from a place were you go to be instructed and lectured. And it is of course a place, which reminds you of the times when you yourself have been a student. And it is a sound foundation for the friendliness of the people from DAQUAS and all the attendees.
I know, one can see it differently - but why does anybody go (or is sent) to a DevCon? Certainly not to relax on the sides of a fancy swimming pool with a cool drink in his hands.
And of course there is ample space for fun and joy: Traditionally the evening of the first day is reserved to the developer party: It takes place somewhere downtown or in the vicinity of the city. For those who want to go by foot, this usually needs about 35 to 60 minutes of walking to go from the CTU to the place, where the party is going to be. For the other ones, there are subways, busses, trams, and taxis available to go to the hotel (Prague has an dense network of public traffic services), dump the luggage there, and then you either walk by foot to the developers' party or use public transportation to do so.
And finally there are the people of DAQUAS: A group of determined, always friendly, always helpful people, who always will find a way to resolve larger or smaller problems (see the story about Drew's visa). So you not only feel professionally serviced, you also feel welcomed and cared for.
And do you know, why DAQUAS does not need a Resort Hotel, to get enough attendees to the DevCon? Well the Resort is the city of Prague. People have been working for more than 1000 years to create it. Therefore a
couple of days sight seeing won't do it. To "see it all" you can spend many many months travelling
the city. As nobody has this much time available here is this proposal: Just add a few day to the DAQUAS DevCon
and you have many reasons to visit Prague for many years to come.
So watch out for next year's DevCon - maybe this is the one for you!
At the end my new college, Jan Vit, and myself want to extend our thanks to everybody who helped us preparing this report.
- First of all we want to thank the people of DAQUAS whose never-ending patience and resourcefulness were a great help.
- Igor Vit - His persistence, creativity and never ending friendliness helped a great deal.
- Michel Fournier - He enabled UT, he invented this type of reporting and, above all, showed remarkable patience with us because we constantly missed the deadlines.
- Jan Král - He is Jan Vit's best friend, also 17 years old, and currently a high school student. Since 1999 he has been using Visual FoxPro versions 3, 6 and 7 and has been attending several conferences of DAQUAS. He served us well in collecting facts and information, taking pictures and delivering quite a lot of ready to use written drafts.
- Brent Speedie (son of Drew and Irene Speedie) - Though 11 years young he voluntarily supported us and became our "assistant spell checker" - reading all the texts and finding tons of typos, wrong grammar and misused idioms - we wish our English would be as good as his.
