I've used databases before but Ffenics is weird!

This forum is Read Only . If you feel a thread should be added to the FAQ please contact a moderator

I've used databases before but Ffenics is weird!

Postby Pete Tabord » Fri Feb 01, 2008 4:38 pm

Ffenics is structured the way it is to provide an environment as near to the normal office use of physical paper forms as possible, and to allow systems to be developed with as little knowledge of computer terms as possible.

We regard it as an essential part of the product that there should be no need to separately define the data storage when you have already designed the form.

The result of this is that our terminology maps more to physical systems than other software products, and you shouldn't worry about it. But, if you want a bit of understanding of how things relate, here's the 101.

A real world form of course formats, defines and saves the data you write or type on it. It also presents the data in (hopefully) understandable format to anyone subsequently reading the form. So does a Ffenics Form, with the additional ability to validate and/or derive the data as well. This is unlike the usage of the word 'form' in most other products, where the term typically refers to a 'screen' without inherent data storage.

Neither are our Forms 'tables' as found in other products. For example, a virtual field may well represent data from an entirely different form but which nevertheless can be used as belonging to this form. In this sense the data structure is somewhere between a SQL table and a SQL view, but also has functionality not found in either.

A SQL implementation that had 'domain support' would have the equivalent of Range Checks, and Triggers map approximately to Derivations, so ther is some convergence, but both these are extensions to the original implementation of tables found in SQL products - although Domains are part of the original relational theory.

Technically, the data storage part of a Ffenics form is a 'relation' . Fields are 'attributes', records are 'tuples'. You will not see these terms as you use the product, but they are used in the technology itself and map to the terms used in technical publications on Relational Theory.

Aspects provide one or more alternate ways of interacting with the data belonging to a particular form on screen. It is fair to point out as Rob does that this is nearer to the 'form' concept found in other products, but there are still substantial differences, not least that an Aspect automatically contains all the data validation and derivation of the underlying Form.

Further, both Aspects and Ffenics Forms are 'multiforms', and by means of subforms can contain data from numerous other forms, either in various tabular formats or as visually homogeneous parts of the form presented to the user.

You can create an approximation to a normal entity/relationship model by using the approach recommended by Graham Smith, which is to use Ffenics forms purely to define data structures ('tables' - kinda) , and Aspects to define screens for the end users.

One further note - Ffenics is not an open ended programming language - it is a database management system with extensive predefined functionality. The scripts you can write in our language (PSL) are in effect macros calling that functionality, you cannot write new functionality of your own. However, you can create external functions or function libraries of your own in the language of your choice and install them into Ffenics, and you can also call existing DLL's, either MS or third party.
Peter J. Tabord
Head of Development
Database Software Ltd.
ptabord@ffenics.com
Pete Tabord
 
Posts: 1881
Joined: Fri Sep 07, 2007 12:48 pm
Location: Caernarfon, Gwynedd, UK
Has thanked: 0 time
Been thanked: 3 times
 
 

Return to Ffenics FAQ

Who is online

Users browsing this forum: No registered users and 1 guest

cron