WO1994017477A1

WO1994017477A1 - Data transfer, storage and handling means

Info

Publication number: WO1994017477A1
Application number: PCT/GB1994/000187
Authority: WO
Inventors: William Frederick Cawley
Original assignee: Ambit Research Limited
Priority date: 1993-01-29
Filing date: 1994-01-31
Publication date: 1994-08-04
Also published as: AU5890694A

Abstract

A data transfer system is arranged to create two files, one containing the names of the items extracted and the other containing the items themselves. The data may be used in a multi-user system arranged so that if a change is made in the data of one database the same change is made in the data being used by the other user at the same time.

Description

DATA TRANSFER, STORAGE AND HANDLING MEANS

The invention relates to the transfer, storage and handling of data, and more particularly to such steps using computer and like equipment. An electronic spreadsheet is a layout analogous to an accountant's ledger sheet having many columns and rows in which data are entered. The data may be subjected to a variety of management tasks such as audit, forecast, variable analysis, market planning, corporate strategy planning and the like.

The advent of the personal computer has highlighted the need for suitable programs whereby managers can store and manipulate their own information without calling on the skills of outside technicians to construct programs for them. The spreadsheet presents the user with a cell structure on a two dimensional plane, the cells of which may be defined by the user to be constant or to be based on formulae, which are enacted as the source values of the formulae are entered or changed on demand.

The conventional spreadsheet stores its information within the same structure as the cell headings, and each data value has no significance outside its position in the spreadsheet, thus limiting the amount of data that may be handled with confidence to a very small proportion of that which may be required.

In our patent application no. PCT/GB90/01554 published as WO 91/06059 (agent's ref: P00063PCT), there is described and claimed a particularly efficient and advantageous method of setting up a spreadsheet. "Context" is the term used to identify the additional information required to define unique/y the contents of the cells containing data in a worksheet, hi our patent application no. PCT/GB92/01121 published as WO93/00642 (Agent's Ref: P00445PCT) there is described an extension of that invention which provided a means for the transfer of data in a similar form to existing spreadsheets, (LOTUS, EXCEL etc.) set up on any computer system and not just one set up according to the technique of the earlier case. More particularly there is described and claimed in that patent application a data transfer and storage system, comprising an interface to be connected to the program controlling the spreadsheet source database containing the data, the interface including means for defining the data to be extracted from the source database and identifying the Context thereof and means for storage of the extracted data. It is intended that by these references the entire disclosure of these two earlier documents is enclosed herein.

It is one object of this invention to provide a further refinement of this technology. It is another object to provide a data handling system which is particularly versatile.

According to the present invention in one aspect there is provided a data extraction system comprising interface means arranged so that data is extracted from a database and entered into a database by means of two separate files, each of which has a dedicated module therefor, one file to contain identification of the extracted data and the other to contain the extracted data.

For convenience, in this aspect of d e invention we call the first file a Names File (.ADN) and the second file a Data File. Each file has as the first two bytes a version number, e.g. 16 decimal.

(As far as we are aware, nobody uses two separate files of the same form for the accessing of data from a database (this is clearly distinct from the common form of header and data files where the header defines the "fields' in the corresponding data file). The advantages of two files are that the data records (which must each be labelled with a number of names) are held in the most compact form, that each 'name' is stored only once, and that the 'names' may be changed while still preserving the sense of the data (e.g. mis-spellings may be corrected).

Traditional 'headers' specify a number of 'fields' which constitute a 'record'. The data file then consists entirely of 'data' conforming to the specification in the 'header' for a 'table of records').

THE NAMES FILE (.ADN)

This file comprises a list of names that have been used or may be used as tags or other identification for data. Names are held as text, and are usually alphanumeric, but may contain any printable or visible character. Example names are

1992, Total Sales, New York, Actual, Widgets

The primary purpose of the .ADN file is to assign a number to each name. Preferably the .ADN file allows for 'features' to be stored against each name. Features may be a list of any other names that may be contained in the set defined by the name in question (e.g. the name 'Points of the Compass' may have the set 'North', 'South', 'East', 'West' as its feature 1) or the source information identifying when the definition of the name was established or last changed, and by whom.

The file thus primarily consists of a leadin of two sectors to contain general information about the file (i.e. the number of records on the file, where the index starts, etc), an index that points to the name records, and the records themselves. The records each start with a two byte record length, then a single byte to show thie length of the name, then the name itself in ASCII with a null terminator. If the record length is then odd, a padding null byte is inserted before the list of features if they exist.

Each feature consists of two bytes showing the feature length, then two bytes showing the feature type, followed by the feature information itself. In the case of the list feature above, the feature information is two bytes showing the number of elements in the set, followed by integers showing the record numbers of the names in the set.

Preferably three ancillary features are present, namely

1) The file also incorporates a list of the record numbers sorted into Alphabetical order, which is constantly maintained, and greatly simplifies the display and operation of list boxes where the user is asked to make a choice from the file.

2) The file incorporates space for encrypted password information. Where there is a password set, only those that know the password may have access to the file.

3) The file incorporates space for 'Locking' information. On a multi-user system this will show which user, at any time, is asking for write access to the file, and will ensure that only one user obtains such access at any time. This information is held internally so as to make the system independent of the system that controls the access on the network on which the present system is running. The Data file comprises records, each representing an item of information. Such information is usually a number, text or a date, a pointer to a photograph, a video, a sound track, or the like.

The required features on the Data file are thus

1 ) A Leadin which indicates the start and end section of the data.

2) the data itself which comprises records each being an individual item of data.

Each item of data is considered to be a record, and has the following form:

BYTE record length

BYTE number of names

INTEGERS one for each name, in numerically ascending order.

PROVENANCE FIXED INFO (see below)

SUBRECORDS if necessary

BYTES data type

BYTES DATA

The PROVENANCE FIXED INFO consists of

INTEGER source (another NAME in the name file)

4 BYTES Initials of who last changed the data (ASCII)

4 BYTES Date and time in Microsoft compatible form

THE SUBRECORDS each start with

BYTE with top four bits set; subrecord type

BYTE subrecord length

The only subrecord types are 255 (FF hex) which defines the way in which the context is to be set in the source worksheet when the user asks to be taken back to source, and 250 (FO hex) which is defined to be the notes attached to the record. All other subrecords must have types between these values.

Preferably the items of data are stored directly sequentially starting at the beginning of each sector (in DOS a sector is 512 bytes). The last item in a sector will be terminated by a 0 byte to indicate a record length of 0 for the next item. If an item is removed, it is marked as deleted by setting bit 6 of the names count byte. No attempt need be made to fill that space until re-indexing takes place. In accordance with this aspect of the invention no item is allowed to cross a sector boundary.

To provide for fast access to the file, the invention preferably includes sort means to sort the names file by alphanumeric order of the names set i.e. a sorting capability. There are two forms of this sorting:

1) Sorting on the names. In this form, the records are sorted on the whole record apart from the first two bytes.

2) Sorting on one or two sets as a priority, then the names thereafter. In this form, in each record a search is made in each record for an element of one or two sets, and these elements are made the primary and secondary sort keys before a sort of the full record apart from the first two bytes.

In this form, a separate index is kept pointing to the sectors containing each combination of two elements (one from each set). The index allows the data access module to reject sectors from a search pattern without loading them.

In this form also, the data may be stored with each record after the first in any sector optionally being stored only showing the difference between that record and the last record stored in its full form, so shortening the stored length of the record considerably.

The shortened form consists of

BYTE Record length

BYTE bit 7 is set to indicate that this is a shortened record the bottom four bits point to the position in the list of the single name that differs from the last record stored in the full form. rest of record those bytes at the end of the record that differs from the last record stored in the full form

Most preferably, the spreadsheet interface to the system includes three functions, which we call ADDATA, ADCHOOSE and ADSET. (The prefix AD stands for Analytic Database).

ADDATA (<dbase>. <range>, <context>)

PURPOSE: Defines a range to be filled with data from an analytic database.

<context> is a set which may include one or more ranges specifying column headings and one or more individual items that would apply to all cells in the data range. The elements are comma separated.

This function specifies that the <range> is to be filled with data from the <dbase> using the labels in the ranges and cells of <context>. Each cell of the data range will be abelled' with the relevant label from the row and column headings and all the other labels specified, providing those labels exist in the named database. These context lists will be interpreted into 'request lists' to be sent from the application to the server (see below) which is responsible for maintaining the databases: e.g.

ADDATA ("sales", C8:G18, C6: G6, A8: A18, D2, D4, "1992")

In this example specifying 11 columns and 5 rows, the specification would be translated into a request list for 55 individual items of data.

Note: if this instruction is applied when no "sales" database existed, the user is asked whether to initialise the database, and the database together with the labels in the context is set up automatically.

ADCHOOSE (<dbase>, <cell/range>, <set names>)

PURPOSE: Allows the user to obtain list of possibilities of label names to fill given cells.

<set name> is the name of any label, but specifically implies that that label is associated with a set.

In case the entry is not specific, a list of alternatives is presented to the user, and the label chosen is replaced in the cell.

Thus the return value of the function may be considered to be the value placed in the cell, but the function may also be used directly as a range parameter in the ADDATA function, to return a range.

ADCHOOSE may also be used to introduce new labels, and it's functionality may be customised as specified overleaf.

ADSET (<dbase>, <range>, <set name>

PURPOSE: Fills the <range> with elements of the <set name> from the <dbase>.

This is often used to fill a range in the ADDATA function parameters.

Edit Sets

The user specifies the file and set. He is allowed to re-specify the elements of the set.

TERMINOLOGY

A Name is the string which may be the contents of a cell, or any expression involving contents of cells and constants.

A Set is either a Name or a series of Names separated by commas enclosed within { } e.g. {North, South, East, West}

The characters ; and, are operators. The former is used to separate additional instructions (see below), while the latter is used as a list separator as above.

Names passed in functions may contain wildcard characters (*), or may be an expression containing more than one label and/or wildcards. The operators are:

+ Union of two sets

* Intersection of two sets

~ Not (unary set operator) Names may contain the operator characters, but if they do so, then they should always be used in expressions enclosed in ' marks with blanks before and after:

e.g. 'this is a name containing the characters !-'

In addition, various 'commands' allow the user to customise the ADSET and ADCHOOSE functions. These customisations appear as new 'lines' of code, separated by semi-colons, at the end of any name.

on ADCHOOSE

TITLE <string> to be shown at the top of the list box

EXCLUSIVE only consider elements of the givsn set

EXISTING do not allow new elements to be added to the set

ELEMENTS

SETS display the elements of the named set, and do not investigate the subsets

CREATE do not ask for confirmation if the name is a new name on ADSET

ADO do not ask for confirmation before adding to sets

on ADSET

TITLE title on a list box if CHOOSE is specified

CHOOSE specifies that a choice is to be made from the set named

SUPERSET specifies that the choice is to be saved as a name set FIRST <name> specify the first of the set for select

LAST <name> specify the last of the set for select

COUNT <integer> specify the number of elements to select

These last three functions may be used in any combination of two if desired, and the count may be in reverse; e.g. Months; first Jan 93; count-4 would select Jan 93, Dec 92, Nov 92, Oct 92.

e.g. ADCHOOSE ("sales", C4, "ALL TOWNS; TITLE please choose a town; EXISTING) would specify that the title on top of the list box was to be as specified, and that no new towns would be allowed.

ADSET (*TON I ALL TOWNS ;CHOOSE;SUPERSET SOME TOWNS ENDING IN "TON") would allow choice of towns ending in 'ton' from the set ALL TOWNS, and save the new concept in a set called SOME TOWNS ENDING IN "TON"

It is a much preferred aspect of the invention that each worksheet file becomes a template which can be used repeatedly. Each time a Context is changed in effect a blank worksheet is created and the established formulae still apply. Data can then be drawn into that new worksheet and be used using the established formulae.

In a preferred aspect, the system includes a module called a server to be the central co-ordinator of all analytical database information.

Each region is seen by the server as a 'request list' of data, and is allocated an identification or handle to the 'Application Index'. The 'owner' of each region is the application or 'Client' in which the region appears. The server maintains an index to all 'open' Application indexes showing the clients to which each index belongs.

Communications between server and client is usually initiated by the client, but the client must regularly ask the server whether is any information to be passed back. The server may, if necessary, prompt the client to make such a call. There are two types of information that can be passed back; information that the data relating to an application index has changed, and a request to respond to a 'Source' message. This request, initiated by the user, requires the system to display the source document of any item of data in the correct configuration so as to show the item of data for which the user is requesting source information.

The server is capable of handling calls according to the following schedule, which is published as the 'export function list¹ from the server DLL, as part of a 'C language header file. This list is included to show the full current scope of the server capabilities.

int export FAR PASCAL Totolnitialise (HWND, LPSTR);

/*HWND is handle to current window in all calls LPSTR is name of application returns Client ID*/

ATOM export FAR PASCAL TotoInitDatabase(HWND,LPSTR);

/^♦LPSTR is database name returns DatabaselD*/

int export FAR PASCAL TotoDeleteDatabase(HWND,LPSTR);

/*LPSTR is database name returnsO*/

int export FAR PASCAL TotoInspectDatabase(HWND, LPSTR); //as above

long_export FAR PASCAL TotoFindName(HWND,ATOM,HANDLE);

/* ATOM is DB.ID handle is string to fin returns Name number in DB*/ char far* export FAR PASCAL TotoGetFearure(HWND,ATOM long,int);

/*ATOM is DB.ID long NameNo int Feature no. 0 = Name, 1 = Sϊt returns pointer to feature */

struct Servlnfo export FAR PASCAL TotoFindData(HWND,int,ATOM, HANDLE);

/*Int is Client ID ATOM is DB.ID

HANDLE is handle to template consisting of int Search type (SEARCH_TABLE_or SEARCH_SOFT) union (null terminated list of null terminated lists of integers (as set up by 'inspect database') for SEARCH_SOFT

template null terminated list of blank data items for SEARCH_NORMAL

returns structure consisting of: AppIndNo (see below) hAppIndex points to hlndex (long item numbers) hindex points tohData(loήg offsets) hData data records */

BOOL_export FAR PASCAL TotoInform(int,HANDLE);

/*int is AppIndNo

HANDLE is handle to a list of changed data in the form char length of item record long position of item in Application Index long number of source region to be placed in fixed provenance info, subrecord and data portion of amended record.*/

int_export FAR PASCAL TotoSaveData(HWND, ATOM, int);

/*ATOM is DB.ID int is options for Save dialog box*/

int_exρort FAR PASCAL TotoCloseAppIndex(HWND,int);

/* int is AppIndNo */

int_exρort FAR PASCAL TotoShowSource(HWND,in ong,int,HANDLE);

/* ind AppIndNo; long Dataltem; int SourceNo (to put on backtrack record) HANDLE data subrecord used by Application to reinstate the context on backtrack Record starts Oxff, char reclen. where reclen is the length of the rest of the record. */

struct AD_SourceInfo export FAR PASCAL Totolnformation(int);

/*int iClient returns a structure consisting of either:

SOURCE_REQUIRED (an integer) atmFName, the data file on which the record resides hSourceData, handle to a data record (see above) or

INDEX_CHANGED (an integer) AppIndNo the number of the changed index or

0 (no messages to send)

In another aspect, the invention concerns handling of data by a user. A user who is 'multi-tasking' and may need a data handler that allows him to share data between applications without necessarily committing that data to permanent (i.e. disk) storage. It is one object of this invention to allow many applications to access and amend data from many databases simultaneously, all applications having access to the latest values of the data.

To recap within the context of this invention, data is considered to reside in 'databases' consisting of 'values' each of which has an identifier or a tag. By way of example in the relational database context, a 'database' might be the name for either a collection of tables, or an individual table; a 'value' might be a single number, an alphanumeric string, or a combination of values (perhaps a line from a table), or even a picture, a sound, or a video; the identifier or tag might be a combination of the index fields and the column or field name. The identification means is unique to the data so that every item of data may be identified by the database name and the tag.

According to the invention in yet another aspect there is provided a data handling system for use in the extraction and manipulation of data in a source data base, each item of data in the database being separately identified, the data handling system comprising:

1) Original data buffer means wherein some of the data present in the source database is reproduced;

2) Amended data buffer means arranged to hold an item corresponding to each item of data in the Original data buffer means but in the form in which it has been amended by a user of the data handling system;

3) Data Index means arranged to list items of data by identifier and location in the Original data buffer means and in the Amended data buffer means and information relating to the position on disk from which the item was extracted, whether the item has been changed and a list of Applications Index means (as defined below) that are using each item of data;

4) Applications Index means arranged to list the position of records in the Data Index means which records relate to items which have been requested in a Request List by the or each user.

Preferably the system also includes Sort Index means recording all items of data entered in the Data Index means in a predetermined order.

In another aspect the invention provides a server comprising a plurality of systems as just defined each associated with a different database and arranged so that a user of the server may access each of the databases.

Preferably the server is arranged to serve from one or more Request lists for each database which define the items of data to be extracted from that database, to be presented to the user.

Preferably the server is arranged to present to the user an Applications Index for the Request List on the selected database.

Preferably, the server includes Alteration means arranged to enable the client to inform the server of any alterations made to values of data in any Applications Index whereby the server amends the relevant Amended Data buffer according to instructions from the user which identify the data by its position in the Applications Index. Preferably the Alteration means is arranged to alter a record in an Amended data buffer means by deleting the existing record and creating a new record for that item of data.

The data may be stored and preferably the server includes means to store data in an Amended data buffer means on a carrier medium, e.g. a disk. As indicated the 'pool data' is controlled by a 'server' which accepts instructions from individual Applications. These instructions must include the following:

1 ) A request to make available to the application a 'Request List' from a given database, the 'Request List' being a collection of identifiers for which the application wants to know the values. The server replies to such a request by presenting an Application Index which points directly to the values required.

2) A request to adjust the values of named elements of the list that has been previously requested. By the system of this invention other applications which are accessing the same data will be informed of relevant changes, and they will have access to the new data through the Data index that they already possess.

3) A request to save the data to disk or other carrier medium for a given database, or, conversely, to reload the values from disk to overwrite any changes that have been made.

4) A request to discontinue any of the indexes set up through (1) above.

In the invention the pool server preferably maintains, for each database, the Original (ODB), the Amended Data Buffer (ADB), the Data Index (DI), the Sort Index (SI) and several Application Indexes (Al). The functions of each of these buffers is as follows:

The Original Data Buffer (ODB) holds the original values of any data loaded off disk. This serves two purposes: to detect any values that have changed should a save request be issued, and to detect if any third party has changed data on a networked system if, at the time of saving data, the disk values are no longer equal to the values in the ODB.

The Amended Data Buffer (ADB) holds the current values of all data from a single database which has been requested by any Application, each item in the ADB corresponding to one in the ODB.

The Data Index (DI) holds pointers to both the ODB and the ADB (only the latter being made available to the user) as well as recording the original position of the data on the disk file, a flag to indicate that the data has been changed, and a list of the Application Indexes that point to each data item.

The Application Index (Al) consists of pointers to the DI for each item from any individual 'Request List'. Every time a request is made by an application for information, the results of that request are held in an Application Index (Al). There may be many AIs maintained for a single application and/or a single database.

The Sort Index (SI) is provided to enable the pool server to discover quickly whether items in a new 'Request List' are already in the data buffers. It consists of pointers to the DI sorted in the order of the data tags. Sorting is preferably carried out by an hierarchical technique

On receiving a request for a new 'Request List', the pool server first searches to see whether the database involved is already within the pool server. If not, it finds the database, and sets up the required buffers, currently empty. It then sets up the DI index, simultaneously creating an Application Index, and finds and loads the Request List, marking each item as having an Application Count of 1, and creates the Sort Index.

If there is already a relevant data buffer, the pool server uses the Sort Index to discover whether each item of the Request List is already in the buffers. If so, then the Application Count is raised by one, and a pointer to that item is placed into the Application Index. If not, then a new Data Index is created for that item, and an identifier with no data is appended to the two data buffers. Once the whole Request List has been scanned, the database is scanned to discover whether there are any of the new items, which are then loaded into the two buffers. The Sort Index is then updated.

When a request to alter data is received, that request makes a reference to the relevant Application Index, and the position of the item in that Index, together with the new value of the item. The Pool Server makes up a new record (consisting of the tag and the value), and adjusts the Amended Data Buffer accordingly. Since the new record may be a different size from the original record, the method employed is to extend the ADB by adding the new data to the end, and mark the old data as being no longer in use, while keeping a count of the total deleted space. When this count reaches a trigger point, a housekeeping operation compacts the ADB and adjusts the DI. The Pool Server also keeps a note that the alteration has been made. The Pool Server may also add record information about the source application, date and time of change, and person who changed the record.

If the Application Count for that item of data is greater than 1 then the Pool Server finds the other affected AIs and informs the Application accordingly. For this purpose, a flag is held in each Application Index to show thai: it has been changed. The flag is cleared when the client makes a Totolnformation call which sends through the information that the index data has changed. A request to Load the data will clear both the ODB and ADB and reset out the Indexes and then reload both buffers from disk.

A request to Save will discover which values have changed by comparing the ODB and ADB, and commit the changed values to disk.

A request to remove an Application Index will reduce the Application Count of all the items in the index by one. If any are reduced to zero, the data is marked as deleted, and the index item is marked as re-usable. A 'chain' of unused index pointers is maintained to enable the Pool Server to find a spare data index quickly (on the 'first in, last out' principle).

In order that the invention may be well understood it will now be described with reference to the following Examples given by way of illustration only.

Example I

Figure 1 is a flow chart of the operation of a pool server of the invention showing three separate Applications each accessing and manipulating information from two of three separate databases. The pool server creates an ODB for the items of data reproduced from each database and a respective ADB for those items in the ODB which have been altered. The respective DI provides pointers to the position of the items in ODB identifying their position in the disk or other carrier medium and a flag to show those items which have been changed; it also records which of the Applications has been using that data. The SI lists the items in the DI and is arranged to sort them speedily so that they may be recovered quickly. In this instance each Application has two AIs, into two different databases, and each database has two AIs for different applications. The buffers for database 1 are:

ODB 1 Tag 'A' Value "Value of A"

2 Tag 'B' Value "Value of B"

3 Tag 'C Value "Value of C"

6 Tag 'F Value "Value of F"

ADB 1 Tag 'A' Value "Value of A"

2 Tag 'C Value "Value of C"

5 Tag ^*F' Value "Value of F"

6 Tag 'B^* Value "New Value of B"

DI 1 ODB 1, ADB 1, Disk position .. AC 1 Unchanged, AH

2 ODB 2 ADB 6 Disk position .. AC 2 Changed, All , AI2

3 ODB 3 ADB 2 Disk position .. AC 1 Unchanged, AH

6 ODB 6 ADB 5 Disk position .. AC 2 Unchanged, All , AI2

SI 1,2,3,4,5,6

(The tags here are already in order)

Al 1 Database 1: 1,2,3,6

AI 2 Database 1: 2,4,5,6

Claims

1. A system for the extraction of data from a database comprising interface means arranged to provide two files of substantially the same form, one file to contain identification of the extracted data and the second to contain the extracted data.

2. A system according to Claim 1, wherein the identification file contains the names identifying the extracted data records and a number assigned to each record.

3. A system according to Claim 2, wherein the names are held in alphanumeric form.

4. A system according to Claim 2 or 3, the names file includes an Index of the name records.

5. A system according to any of Claims 2 to 4, including a list of record numbers arranged in alphanumeric order of the corresponding names.

6. A system according to any of Claims 1 to 5, wherein the second file comprises a data file made up of a leadin which defines the start and end section of the data, and the data section itself which comprises records each being an individual item of data.

7. A system according to any preceding Claim, including sort means to sort the names file by alphanumeric order of the names text.

8. A system according to Claim 7, wherein the system is arranged to son data by numeric order of the names on the data items or by primary and secondary keys, each key being a numeric set of names of which any data item may share an element, then within each primary and secondary key by the rest of the names that apply to the data item.

9. A system according to any preceding Claim, associated with spreadsheets including a function 'ADDATA' to define a region of a spreadsheet to be filled with data from an analytical database and defining the database, the range and the context (as herein defined).

10. A system according to any preceding Claim associated with spreadsheets, including a function 'ADCHOOSE' and defining the database, the call range and the set name.

11. A system according to any preceding Claim associatϊd with spreadsheets, including a function 'ADSET' to fill a range of a spreadsheet with elements of a set name from the database and defining the database, the range and the set name.

12. A system according to any preceding Claim, in association with a server arranged to maintain databases by a system according to any of Claims 1 to

7.

13. A system according to Claim 12, in which the server is arranged to access a number of databases and is arranged so that if one user changes data in a database the changes are notified to other users of that data.

14. A data handling system for use in the extraction and manipulation of data in a source database, each item of data in the database being separately identified, the data handling system comprising:

1 ) Original data buffer means wherein some of the data present in the source database is reproduced;

2) Amended data buffer means arrange to hold an item corresponding to each item of data in the Original data buffer means but in the form in which it has been amended by a user of the data handling system;

3) Data Index means arranged to list items of data by identifier and location in the Original data buffer means and in the Amended data buffer means and in the or each Applications Index means (as defined below), and

15. A system according to Claim 14, including Sort Index means recording all items of data entered in the Data Index means in a predetermined order.

16. A system comprising a plurality of systems according to Claim 14 or 15, each associated with a different database and arranged so that a user of the server may access each of the databases.

17. A system according to Claim 16, arranged to serve from one or more Request lists for each database to define the items of data to be extracted from that database and to be presented to the user.

18. A system according to Claim 16 or 17, arranged to present to the user an Applications Index for the Request List on the selected database.

19. A system according to any of Claims 14 to 18, including Alteration means arranged to make an alteration in the Amended data buffer means of a database corresponding to an alteration of the source da .abase made while the user is connected by the respective system to that database.

20. A system according to Claim 19, wherein the alteration means is arranged first to identify the position of an item to be altered in the Application Index means of a database and then to cause the alteration to be made to that item in the corresponding Amended data buffer means.

21. A system according to Claim 19 or 20, wherein the Alteration means is arranged to alter a record in an Amended data buffer means by deleting the existing record and creating a new record for that item of data.

22. A system according to any of Claims 14 to 21, wherein individual Applications are arranged to provide instructions to the system in the form of a request to make available to the application a 'Request List' from a given database, the 'Request List' being a collection of identifiers for which the Application wants to know the values, the system being arranged to present an Application Index which points directly to the values required.

23. A system according to any of Claims 14 to 21, wherein individual Applications are arranged to provide instructions to the system in the form of a request to adjust the values of named elements of the list that has been previously requested whereby other Applications which are accessing the same data will be notified of those adjustments.

24. A system according to any of claims 14 to 13, comprising the Amended Data Buffer, the Data Index, the Sort Index and a plurality of the Application Indexes.