DataEase for DOS (DFD) Patch Installation Instructions Unzip the downloaded zip file into a clean directory and run 553.exe. 5.53 README This file documents changes in DataEase since DFD 5.10. 5.53 changes are given first, followed by new features (none since 5.16) and manual notes. Then there is list of bug fixes from 5.11 up to 5.17, and finally some general advice. SPR (Software Problem Report) numbers are given where relevant for reference. Some bugs were given a different number in the UK. Not all SPR's turn out to be bugs! Problems labelled 4.53 and SPR's prior to 3018 were first reported in DFD 4.53 or earlier. This is very likely to be the LAST maintenance release of the DOS version of DataEase. The DOS product has been on maintenance since 1995, and 10 years on it seems an entirely reasonable time to lay the old dear to rest. ############################ IMPORTANT COMPATIBILTY NOTES ############################ DFD 5.53 is supplied as single user or 'upgrade' packs on CD only. If you require additional users for a current system you should install the extra users' programs on their local workstations. Each such installation will add a user to the maximum number that may be logged on to the application. See installation notes supplied. DFD is a MS-DOS product! It is compatible with MS-DOS 5.x to 6.22, and IBM PC-DOS versions 5 to 7. DFD is NOT guaranteed compatible with Windows DOS boxes etc, however it has been tested with Windows 9.x, NT, 2000, XP Pro and 2003 server. It gives generally satisfactory results on these platforms, but there may be limitations where hardware support etc. is concerned. (e.g , Windows-only printers, USB and CD/DVD support). We are NOT responsible for any shortcomings in the DOS emulation of these or other environments. In some circumstances memory leaks will be visible on workstations running NT or subsequent versions of Windows. The leaks are from the NTVDM supplied by Microsoft, and are NOT under DataEase's control. It is not clear whether such leaks are caused by the compiler we use, the libraries we use, or the operating system. However, no leaks occur on DOS or Win 9x platforms, and no leaks are reported by DOS or DOS tools. Since DFD and these tools are in the main unaware of Windows, no cure seems to be possible from 'our' end. ) Similarly, on the above machines, DFD seems unable to use virtual memory. Only DFD 5.15 and later are certified y2k compliant. Do NOT use the system locations feature! Views, masks and conditional field attributes are not supported in the current DataEase product line. Similar (not identical) features are provided, but as these require reprogramming we suggest you limit your use of the above features. There is a wide variety of new features introduced in the DataEase product since it 'moved' to Windows in 1994 - frequently these newer features make some of the more complex or devious techniques needed in DFD obsolete. Multicolumn (compound) indices will be supported in a DFD-compatible way in DataEase for Windows 7 (i.e. they will be automatically upgraded, whereas currently they have to be removed in an application using a more recent version of DataEase. For your own protection you should endevour where possible (after your own acceptance testing!) to be on the latest shipping version of product. There is available on the DataEase website a detailed document dealing with network installation issues on modern platforms. Interoperability with current DataEase will CEASE with the release of DataEase 7 as our Windows product will be updated to the 64bit file system of Windows NT and later. An upgrade path direct from DFD5 to DataEase 7 will be provided, but will require some development effort to create a working application. Essentially tables, data, and DQL's will be brought forward, but not menus, screens, report formats or QBE's (the latter can be converted to DQL's prior to moving). Apps that have both DFD and DFW elements will be upgradeable to DE7, with DFD elements that are incompatible (i.e. the "not's" from the above list) stripped out. Users of DataEase 7 will continue to be able to access in a limited way data in DFD 5.53 applications via the DataEase OLE DB Provider - a fully operative version is supplied with DataEase 6.5x and DataEase 7. ############################ This is now a very long document. But, please take the trouble to read it - you will save time in the long run! Changes in DFD5.53 ------------------ DFD 5.53 has been tested with Windows 2000, Windows XP Professional and Windows 2003 Server. Note that you may have to change your DOS session pif settings to get proper mouse behaviour when running in a window under Win 2000 and later. Try quick edit off and exclusive mode on. MEMORY MANAGEMENT FIXES A complete overhaul of memory management has been undertaken to eliminate memory leaks and to reduce the incidences of gpf's. This includes the following measures: Updated 16M library to latest (last!) version. Replaced all (virtually all) old type D16 calls with d16 calls. Remade all Assembler modules for 286 CPU to be consistent with C modules CDF libraries are now unloaded each time execution returns to a control procedure. Failure to correctly identify current memory available caused 16M memory manager to have problems, resulting in failure of sort. Typical visible effect was that the first record in a report was printed out the number of times that there should have been different records in a report. (i.e., if a report printed 50 records in order the first record repeated 50 times). Improved error trapping if memory exhausted. (But note - in some environments DFD cannot uase virtual memory and may abruptly stop when physical memory is exhausted - see compatibilty notes) A number of silly gpf's in procedure definition fixed. Plus some serious ones. Numerous minor memory leaks have been removed. Experimentally, relationships limit raised to maximum (practically, 250). Arbitrary fixing of relationships to 40 in some situations in reports fixed so 200+ can now be used. Buffer for loading forms increased from 32k to 48k - varius other buffers enlarged or given 'intelligent' scaling to suit available memory. OTHER FIXES in 5.53 Failure to reset some counters sometimes caused a record of a report to be repeated several times. Fix for lockouts on Lan Manager and MSNet type networks if machine left on sign-on screen. Fix for damaging behaviour if user tried to logon with duplicate DENAME by ignoring 'Duplicate DENAME' message when there really was a duplicate. (It could corrupt DENETWRK.OVL or lock up all users) Fix to tests aaginst BLANK in interoperability situation. DFD 5.16 New features and clarifications. ------------------------------------------ The date range in DataEase products MUST be set so the current date is in the valid range! Even if you use only extended (four digit year) dates, the date range is used for determining the century for generating current 'extended date'. STACK SIZE If after upgrading from 4.53 or earlier you find certain large reports won't run or large forms won't load, you have quite likely run out of DataEase Internal Stack. Increase this using the command line paraneter '=' (documented in the manual). A batch file (DE16L.BAT) is included as a sample. The default stack has in any case been increased to 50000 from 30000. RELATIONSHIPS A new error message has been introduced which will hopefully prevent DataEase GPF'ing when too many relationships are attempted to be opened. This message is 'Memory error opening relationship nnn". If a user receives this message when F10'ing, he should escape back to a menu. The normal message is "System Error:Relationship limt nnn exceeded" In both cases the nnn will display the relevant number of open rels. The new message should only be encountered when the relationships limit in Ztermdef.dbz has been increased to a high value - over 240. Please report any instances of it appearing 'earlier'. If you still experience any cases of GPf's or other unrecoverable errors which you believe are due to running out of relationships and were NOT preceded by either of the above messages, please double check your FILES= allocation. If that is satisfactory, then please report the problem - we shouldn't accept this as just being normal DataEase behaviour! NEW FEATURE - 'SMART' extended dates Partially typed extended dates now default. Any part-field left blank or zero will default to the 'current' value, and part typed years will default the century. So, for example, typing 01/01/11 this year will give 01/01/1911 and next year 01/01/2011. A special case has been made for any number of zeroes in the year field. This will always give 2000, so 01/01/00 will give 01/01/2000 and not 01/01/1999 as it should (for a current date in 1999 anyway). Similarly, to help us for the next 10 years, a single digit date is assumed to be preceded by a zero, so typing 01/01/1 next year gives 01/01/2001 and will for the whole of the next century. Since the purpose is to help the typist, it is assumed that the normal requirement is to type a two digit date, so in fact typing 01, 11 etc. for year is natural. Note that searching with wildcards still needs to have a full specification - see below under 5.13. NEW FEATURE - interoperability controls. DataEase now provides control over interoperability. By default, forms can be used by DFW (subject to the already existing limits) but ownership cannot be transferred. There is a new option on Page 1 of Form Properties called 'Owned'. If this is set to yes then the form cannot be acquired by DFW. Forms so acquired cannot (yet) be reliably read by DFD, so if continued inter- operability is desired, the form should be owned and maintained by DFD. Views may be built over such forms in DFW ('form not owning table') if a GUI appearance is desired. Note that DFD 'views' do not transfer to DFW, and that new tables/forms/views created in DFD 5 are set to 'OWNED' by default. DQL scripts can of course be transferred by existing methods, but as this is a non-destructive process the above mechanism was not thought necessary. NEW FEATURE - enhanced message control. If you are displaying a message in a window, you can now turn off the 'press any key to continue' message, or optionally display your own in its stead. To do this, placa a  (alt-127 on the numeric keypad) at the start of the message string. This will suppress the message. If you want to do a message of your own, then do "Your replacement key messageYour Message" You may still insert the window size parameters between the last delimiter and the start of the message - dont leave a gap between the delimiter and the first number. The maximum size of the replacement 'key' message is 40 characters. DFD 5.14. New features and clarifications. ------------------------------------------- FORMAT SYNCHRONISATION. This new facility was introduced in DFD5.13 and refined in 5.14. It enables report and procedure formats to (semi)automatically pick up changes in field formatting that have been made on forms. The area it adresses is where field details are changed but no change is made to field type or field name. Hitherto such changes could result in garbage being displayed by a report, but the only way to reflect the changes was to delete the field from the report format, save the report, reload the report and replace the field. Tedious if it affects dozens of reports, almost impossible if it affects dozens of fields. This facility was made semi automatic (you have to actually load and save the report/procedure with a trivial change such as typing a space somewhere) so you can choose when to change a specific report rather than have change arbitrarily thrust upon you! Also, wherever possible, the actual format you have designed is left undisturbed. For example, it was decided not to change formats for strings (text etc.) to match the form as this could change a format out of recognition! WHAT GETS CHANGED: Changing field type or name will result in the field being deleted from the format. This is as it has always been. Other changes have the following results: Text and Unformatted Numeric String: Length: < format length - will be space filled (as opposed to garbage filled!). > format length - will be truncated to fit format. In this case if you wish the new length to be reflected you can simply edit it on the format - dont't remove and replace. Formatted Numeric String, Date, Time, Yes/No, Choice: Any change: Field on format will be changed to match. Number, Currency: Number Type: Will result in translation between number type specified on format and number type specified in form (again, instead of garbage). Minor changes in field length may result. Max Digits: As for string length. Pos'n of Decimal Point: Not changed - can be edited on format. PgUp/PgDn For clarity, the design behaviour of form pages is If the page contains text only, it displays. If the page contains only PDE and virtual fields, it does not display, regardless of whether it contains text. Conditional PDE is evaluated before display. (Complicated interdependencies on conditionals may break/fool this - make sure what you want to do actually can be handled by the program - we cannot cover EVERY possible combination!) All other pages display. Apart from the all text pages and the evaluating of conditionals, this is mostly as for 4.53. A couple of 4.53 bugs that sometimes caused partial pages at the end of forms to not display, and to push fields into undisplayable hyperspace when the end key was hit in a subform were cured before release of 5.0. 5.13 - Y2000, Extended dates. NEW FEATURES, tips and definitions ---------------------------------------------------------------- Many Y2k issues were first addressed in this release, but note that the first version of DataEase to be fully Y2k compatible is 5.15. See below in this section for new features, tips etc. on many date issues. DataEase two digit dates ('standard' dates) do handle the year 2000. They must be configured correctly in your system configuration form. This permits any 100 year span from 1901-2000 up to 1999-2098. I recommend using something between 1925-2024 and 1975-2074. Be aware that if you change this range you may 'move' dates from one century to another! DataEase correctly handles Feb 29th in 2000. It IS a leap year! NEW IN THIS VERSION - Wild cards searching and selection is now implemented for extended dates (and has been made Y2000 compatible for standard dates). You may use the ? character as a wild card anywhere in a search on a date field. The date must be fully specified, e.g. you must enter 01/01/???? not 01/01/?. If you enter ?? in the year part of an extended date field the century part will be lost - i.e. the search will work as if you had copied the dates to a standard date field first. Asterisks can no longer be entered as criteria in wild card searches on date fields (they didn't do anything anyway). If you use wild cards in a DQL or QBE the only valid tests are = or not =. Testing for > or < or indeed anything else is unspecified and you should not rely on the results. SPR#3173, UK SPR#1330 NEW IN THIS VERSION - 'current extended date'. It is the last field in the 'current' pseudo form so you need to get the F1 list up to see it in interactive DQL. If you use it in a derivation it needs "extended date" in quotes just like other current field names with a space in them. You can also create a field on a report format called current extended date - there it doesn't have quotes - but it will correctly be created as an extended date field. (There is no option when creating a date field on a report format to select type of date field - DataEase will try to determine what kind is needed by what sort of dates it is created over). The ability to use ??/??/?? as a synonym for current date in a standard date field definition remains - however, it ONLY applies to standard date and ONLY in a derivation - in DQL or QBE it is treated as a wild card - as it has been for many years. This feature has been declared obsolete since 2.53! It has been made much simpler to convert an application to use extended date format. All that is now required is to change the date fields on forms - data will be translated automatically - and then resave all the reports. (You'll need to make a trivial change such as typing a space in the DQL or the format). All changes to date formats will then be picked up automatically by the system. BUT! - it will NOT automatically notice that a number field that is calculated as a year() of an extended date now needs to be four digits rather than two, even though the function does correctly return four digits. Date Range. Extended dates start from 01/01/1776. This is not unconnected with the employment of programmers from a certain large ex-colony on the project. But also bear in mind that due to changes in calendar at different times in different countries dates much earlier than this are unreliable. If there is demand I could make dates back to approx. 963 B.C. valid, but you'd have to work out the difference between dates figured back retrospectively from today and 'contempory' dates yourself. Country independance. Extended dates are stored in a common internal representation for all date formats. Standard dates have always been stored in the format they were typed in as. This makes it much easier to transfer data from say UK systems to US systems. Imports. Four digit year dates in ASCII imports may be separated by slashes (or any other non-digit), or just be YYMMDDDD (or whatever the local representation is). Four digit dates may also be imported to standard date fields (with replacement of century by the DataEase calculated one, of course) EXCEPT for metric format extended dates, when extended date fields are obligatory - they couldn't be imported into a date field at all in previous versions. UNIQUENESS AND IMPORTS. Since the introduction of DFD5.0 imported records did not update if they 'matched' on a compound index. They now do. The matching rules for imports which use either of the 'update' options are implemented as follows: All compound indexes that are unique are cumulative. All form fields that are unique are cumulative. Compound index uniqueness and form field uniqueness are not cumulative - this provides for the rare case when two (cumulative if necessary) values are required to be independantly unique: this normally occurs only when a dataless key (e.g. a sequenced field) is used. On an import, the incoming values are evaluated against the values already in the form in two separate operations, one for 'form unique' and one for 'index unique'. If there is no match the record is added (or discarded if 'add or update' was not selected) If there is a matching value on either type of unique but not the other the record containing that value is updated. If there is a matching value on both types of unique and the matching values are contained in the same record then that record is updated. If there is a matching value on both types of unique and the matching values are contained in different records then the incoming record is discarded. This rule is because we do not know which record to update, and in any case updating either record or adding it as a new record will all adding it will violate uniqueness. Hope that's clear! As at present discarded records will update the error log. The 'on screen' counts and add/update messages also now work correctly. NEW FEATURE - System Masks now acessible from main menus - option 8 on the admin menu 'Define Custom Table Views'. This enables the maunual editing of saved custom table views as well as creation of new ones. This is the method by which 'prevent-data-entry' fields can be axed from table view. See also System Masks below - Custom Table View is now fully implemented. BUFSIZE is no longer included with DataEase. This utility has no function with DFD5 and indeed is dangerous to use. You must turn page buffering off before you upgrade any pre DFD5 application to DFD5. Tip - you probably all know this but I didn't, so I'm passing it on in case you find it useful. You may comment out field derivations by inserting the name of the field in brackets () at the start of the derivation - useful if you've got a derivation you can't make work and want to go home! NEW FEATURES ADDED in 5.12 -------------------------- INSTALL A VIEW. Install/Replace a View implented, both from menu options and from a .din file. SPR#3616 The syntax for install.din files is INSTALL/REPLACE FORM formname1 FROM: cfmname VIEW_OF: formname2 DATAREF: Notice that in the remote maintenance option above you supply the formname of the view, not the DOS filename. This protects you from the vagaries of DataEase filenames. Installing from a menu is exactly the same as for a form, except there is a new option 3 when asked what type of form you wish to install - this says 'create a view of an existing form?' You need to give the name of the view you wish to create as the formname, the DOS filename of the form the view is over as the TDF name, and the view's CFMname. A CFM may be installed over any form. If the CFM fields match the TDF it will be installed as a view. If they partially match it will be installed as a view needing resyncronisation, if they have no obvious match the view will not be installed. IMPORTS - There is now an option available for DO NOT MATCH imports that gives a choice between building indicies on the fly (good when importing only a few records) and building them at the end (good when importing lots of records). This is toggled using the 'use batch facility' flag - yes means build indices at the end. Note that all other non-SQL import types must build their indices on the fly so that matching works even against records added or modified earlier in the same run. NEW FEATURES ADDED by 5.11 -------------------------- VIRTUAL MEMORY - In DE4.53, when using DE16M.EXE and its Virtual Memory feature (VMM) you had to create a VMC file to control the location, size and name of your virtual memory swap file. In addition, other memory parameters could be set in the SET DOS16M environment string. DataEase 5 uses a later version of the DOS extended-mode memory manager, which eliminates the need for these VMC files (which should be deleted) and greatly reduces the need for the DOS16M parameter. The SET DOS16M string is now only useful on non-AT compatible machines - for details of supported non-AT compatibles please see the main manual. All AT compatible and PS/2 machines may have this string removed. NEW INSTALL.DIN COMMANDS. The syntax for creating .DIN files has changed due to the new file formats and naming conventions (.DBAs are now split into .TDF and .CFM formats). The new syntax is as follows: install form from: table: data: replace form from: table: data: NEW PARAMETERS FOR Call Program COMMANDS. The following parameters have been added to the Call Program command: %n is the full database name %p is the DataEase program directory %c is the control (DEPATH) directory %s is the default data directory %s[n] is the system location directory for the key value n %s'alias' is the system location directory for the alias 'alias' CUSTOM QUERY EDITOR/Save Incomplete Queries - This feature has been enhanced to create security backups and now gives informative messages about its actions. SPR#s 3080, 3687, UK SPR#1139 THE ENHANCED DATAEASE exec SQL STATEMENT. Syntax: exec SQL ENGINENAME { "SERVERNAME", "DATABASENAME", Destination } `SQL STATEMENT`:VARIABLE|FIELDNAME ; Explanation: Prepares and submits an SQL statement. The SQL STATEMENT will be executed in Dynamic SQL mode. Some statements on some servers have alternate syntax for use in Dynamic SQL mode; also some statements are not legal in Dynamic mode. The SQL documentation for the server should be consulted for further details. The special Dynamic SQL commands for statement preparation and execution are automatically generated by DataEase and should not be entered by the user - they will produce SQL server errors if submitted. Some SQL statements are effectively obsolete in DQL - e.g. exec SQL "BEGIN TRANSACTION" is functionally identical to the straight DQL Begin Transaction. There is no syntax checking in the SQL statement, which must be coded by the user to be syntactically correct for the target server. Parameter substitution is carried out for embedded DataEase variables or field names (indicated by a preceding colon), which are replaces with their current values before the statement is passed to the server. ENGINENAME is the DataEase name for the engine. SERVERNAME and DATABASENAME are as expected by the target engine. "*" will at runtime use the current logon value for the starred field. Different values will direct the statement as appropriate. DataEase fields or variables may also be used. A DataEase form defined over an SQL table can be selected as a destination. This allows (among other things) for the transfer of data from one server to another using a different engine, server, database. The results table should match the select statement column for column. The loop that handles this regards each record as complete if it runs out of target form fields or result row columns. So you can run a select which returns two rows into a Dataease forms with numerous fields as long as the first two rows and fields mach - or vice versa. There are 2 special destinations which are not form or table names: ResultsToScreen: will display the results to the screen as returned. (This was the only option pre 5.0) NoResults: will not update any DataEase tables and will display nothing to the screen. It is intended for use with SQL statements which do not produce results tables like drop table, create index etc.. N.B. It may be useful in some systems to have a scratch table called, say, SQLresult to handle SQL statements that have a single return value. Return: The SQL command's return code is returned in current SQLCODE, and the number of rows processed is returned in current SQLCOUNT The CONNECT and DISCONNECT statements can be used to change the target server. These are also not documented in the manual, but are in the product (and have been since 5.0). Their syntax is: connect ENGINENAME {"SERVERNAME", "DATABASENAME", "USERNAME", "PASSWORD" , CONNECTION RETRIES } . disconnect ENGINENAME {"SERVERNAME", "DATABASENAME"}. If CONNECTION RETRIES is set to > 0 a username/password dialog will be popped up the specified number of times. Entering "*" in USERNAME or PASSWORD in connect will default to the values used to sign on to DataEase, NOT the value used in the previous logon. The above description is taken from the definitive SQL syntax guide currently in preparation by Wolf Data Ltd. It will eventually be published as part of a comprehensive DataEase Technical Reference Manual. FIXES IN PREVIOUS VERSIONS FIXES in 5.17 ------------- You can now create and modify a view. SPR 4237 Handling of DENETWRK.OVL has been modified to improve interoperability on non-Novell networks. Interoperability with 32 bit DFW should be TESTED by yourself to make sure it continues to meet your needs - note that you cannot mix DFD Novell setting with 32 bit DFW - you must use one of the other locking options. Residual parts of network buffering mode have been removed Expiration dates > 2000 are now safely identified Memory handling has been further refined to attempt to get rid of the ctrl-F10 bug - performance may be slightly affected. SPR 4196 Mishandling of blank choice fields on reports - SPR 4233 4253 and others You can now more reliably save a report after you have run it - in some circumstances field format information was being cleared or corrupted. This particularly affected suppress spaces and lead/float fill characters A place was located where the change in list field definition size for 5.0 was not being dealt with - this lead to garbage appearing on reports and format flags for fields being corrupted. DataEase format imports where the new form does not match the old one now works, and is less fussy about extensions. Minor screen overwrite also cured. SPR 4234 and others FIXES in 5.16 ------------- Replacing a view now does work, but: NOTE: If you replace a form that has views based on it, for safety's sake you should replace all its views also. At the very least any such views will demand a resync, and at worst they may be 'orphaned'. Matches between standard and extended dates work even when the extended date is indexed. SPR#4164 Metric extended dates now format correctly. SPR#4161 Mean statistic for dates no longer produce garbage (they shouldn't work - see manual)! SPR#4166 The Date() function now handles negative months correctly. SPR#4162 Spellweekday() no longer returns 'x' if date blank. SPR#4163 Spurious zeros in display of blank/invalid extended date fields eliminated. Failure to delete TDF/CFM's when replacing a form is cured. SPR#4165 Misdisplay in tableview when conditional colors are used has been fixed (again!). Failure of data entry forms to recognise conditional colors cured. Failure of data entry forms to redisplay extended dates after defaulting century cured. Spurious extended dates in blank fields eliminated. SPR#4189 Dates in imports sometimes were imported incorrectly. The rules are now that dates or times with delimiters (typically slashes or colons) may have zeroes optionally omitted in any subfield, but that dates or times with no delimiters must be fully 'zeroed'. e.g. 9/9/99 or 9/9/09 is acceptable but 9999 is not. Three digit years are never acceptable. Dates in an unacceptable format will now result in a blank date, not an invalid date. Dates that are 'properly formed' according to the above rules but invalid - e.g. 30/30/99 - will still be handled as at present. SPR#4201 Numeric strings are no longer truncated if the 'on file' length is shorter than the display length (in formatted strings, for example). This was also the root cause of the date to numeric string problem. SPR#4175 FIXES. in DFD 5.15 ------------------ Invalid extended dates are now redisplayed for editing instead of being lost. SPR#4160 Processing fixed to stop transitory 'invalid' dates being rejected in DQL's etc. SPR#4159 Fixed GPF when doing CTRL-F10 when a taborder exists and the form has multiple pages. SPR#4158 List fields that are expressions which happen to have a field from the form as the left part of the expression are now handled correctly. SPR#4157 Numeric strings now permit the * wild card (as they always should have done) SPR#4156 Virtual fields, groups totals etc. are now behaving properly - in 5.14 they did not get automatically included in report formats. This fix also seems to resolve the problem experienced in 5.14 with jointext fields. SPR#4155 exec SQL returning into formname no longer corrupts report output or GPF's SPR#4158. FIXES in 5.14. -------------- Current time not displaying first digit. SPR#4151 Comparisons to 'BLANK' were not working correctly, causing virtual field derivations to sometimes not fire off. SPR#4154 Forms with the same first four letters as system forms could not be saved. The last fix (in response to a break in 5.13) reintroduces the possibility of getting a cross-linked RDRR form if a .DBM file is missing - although now this can only occur if the missing DBM belongs to a system form, instead of any form as in all previous versions. If you are worried about this run DataBase Status regularly - it will replace any missing .DBM's. DBM's usually go missing because if they are of length 0 (no records in the form) they are not copied by DOS Copy and some backup routines. Always use Xcopy. To cure a crosslinked DBM, install the conflicting form under a new name, and then delete the conflicting version of the form - not the system form! You will not lose any data if you do this straight away. SPR#4142 FIXES in 5.13 ------------- Correctly handles backtab or up arrow through PDE field. No longer corrupts filenames when replacing a procedure or report. SPR#4147 Closes files properly when processing a remote maintenance script (i.e. install an application). This avoids running out of file handles on a big one. (4.53) Deletes DOS files for data-entry forms when they are deleted from the report (4.53) Error traps both DOS error messages meaning 'no more handles' (4.53) PRINT STYLE SCREENS - now respects new path length, as do saved reports. Old style reports are translated automatically, whether last saved in 5.x, 4.x or 2.5. Reports are saved in new format if amended. SPR#4148 Imported blank extended dates no longer produce a corrupt value. SPR#4149 TABORDER - You can no longer include virtual or Prevent Data Entry fields in a taborder. (You shouldn't have been able to anyway, as the cursor won't physically go there). If you have any forms on which you have created a taborder which do include the above field types (note that Calculator fields are allowable) you must remove them from the taborder. For this purpose taborder mode in form design still allows you to move the cursor to such fields. You can then delete them with f6. SPR#3244, UK SPR#1165 Forms which did have such fields 'tabordered' will often exhibit unusual cursor movement when using pgup/pgdn, the arrow keys and the F10 combinations. Taborder is permitted on conditional prevent data-entry fields, but should be tested for acceptable behaviour with the above keys - it is not feasible to cater programatically for all combinations that might be created thereby. F10 or Ctrl-F10 on form with taborder set returns cursor in same way as non-taborder form when returning data or escaping back. SPR#4145, UK SPR#2116 PgUp on form with virtual or Prevent Data Entry fields on as first field on page no longer skips page. SPR#4144, UK SPR#2002 Install no longer loses taborder information. SPR#4142, UK SPR#2090 Install of views has been revised to better cope with error conditions. Auto-update of system forms can now cope with system forms that get smaller. (4.53) Install now deletes the old CFE/TDE when replacing a procedure with a data-entry form with one without. SPR#4140 Curruption of end of files when doing a copy (e.g. when using install to replace something) when the new file is smaller has been cured. (4.53), US SPR# 4139 Missing .DBM's (usually caused by copying an application with DOS copy rather than XCOPY - this loses zero length files) no longer cause crosslinked RDRR's. (4.53) Extended dates derived from standard date fields now correctly interpret changes made in record entry. SPR#4134 Derivations involving comparisons between standard and extended date fields now work correctly SPR#4137 Import bug introduced in beta 2 fixed. Pre 4.0 import definitions can now be accessed in upgraded systems. SPR#s 2663, 4135 Incorrect calculation of century in imported 'four digit year' dates when target field is extended date resolved. SPR#4136, UK SPR#2110 Importing four digit date fields that are blank no longer results in 'invalid date' message and production of error file. UK SPR#1731 Resaving of pre-5.0 imports no longer causes corruption. Imports now support 127 char path/filenames. The on-screen handling is a little untidy but functional. The modified DataEase filenames - the AAEA format - have now been completely removed and filenames will revert to the AAA-AAB-AAC.... format used in 4.53. This means that there is no problem with upgrading databases that have large numbers of forms or reports starting with the sane four letters. SPR#s 3995, 4138 A long standing (since 4.24 at least) error in file handling has been uncovered and resolved. The net effect of the bug was that DE would sometimes copy a file not where intended, but to the immediatly previous file that had been opened. This was especially likely to occur if any disk error (error reading drive F. can't open file, etc.) had occurred, but could also occur when, for example, copying files about in the course of a reorg if the new name that DataEase invented clashed with an existing name on disk. This is the cause of several reported instances of data files ending up with the wrong form. SPR# 2952 for example) The above problem has been encountered more frequently in 5 than previous versions - this is because 5 has more file handling (split TDF's and CFM's, more index types, more system files, etc.) AND more complex file name construction (system locations, the AAEA stuff, etc.), thus more opportunities to trigger this bug. This does NOT mean it doesn't happen in older versions - it was just sufficiently infrequent to be passed off as a 'glitch' For the fix above, paths have had to be addressed. All internal paths in DataEase are now set to at least 127 long. Because the code is confused between 'path' (127 characters) and 'fully extended filename' (144 characters) - too confused for me to sort out in any reasonable timespan - the limit is 127 characters _including_ drive letter and filename. Furthermore, the command line limit is 100 characters, and some 'on screen' limits are even shorter - mainly 'cos I don't want to redesign all the forms! Metric extended dates now work as well as other kinds. Remote Maintenance (install.din) - failure to replace forms/reports and occasional updating of the wrong form on a network fixed (along with other occasional file copy errors - see above). UK SPR#s 441, 2092, 2093 SYSTEM MASKS (Custom Table Views). There was a pathological link between the system masks form and path length(!). The system mask form would lose all its records if DataEase path length was changed. This is fixed (and this version includes a new System Masks form.) The system mask form caused an abrupt exit if you attempted to switch to table view while in record entry on it. The absence of the system mask form no longer causes an abrupt exit from table view - it is treated as a 'soft' error unless you attempt to save or delete a custom table view. The inability to delete PDE/Virtual fields from a table view, reported as an error - SPR#3187, UK SPR#1285 is PAD - you're not allowed to put the cursor there because you could enter data! But you can save your custom table view in System Masks and edit it there to exclude such fields. CDF's. The apparently permanaent disappearance of CDF's on certain machines when certain actions were taken has been fixed. This was a memory alignment bug, so it is very difficult to describe what would trigger it, but those that have it know what it looks like! SPR#4133 Slow loading of CDF's has been speeded up by about 30%. SPR#4124 The limit of CDF's loaded at one time is now 1024. It was 255 by accident - there was supposed to be no limit in DFD5 - this is a compromise as fully implementing the 'unlimited' strategy had unacceptable performace limitations Build up of memory under DPMI and 'dirty' exit addressed by loading/unloading CDF's as for other environments.. (4.53) HOW CDF's WORK NOW - CDF files and libraries are loaded as required by forms or reports when the form or report is first loaded into memory. If the CDF is part of a library the whole library is loaded. When DataEase returns to a menu (an actual displayed one, not a 'chain') the CDF's are unloaded. This means the 1024 limit is unlikely to be an issue, but remember that it is the total number of functions in libraries referenced by the form/proc that get loaded, so if you use one function from each of the Handtool libraries, for example, you actually load 100+ CDF's. CDF MEMORY OVERHEAD - I have EXTENSIVELY tested DataEase and can now detect no memory build up from repeatedly loading/unloading CDF's. If you experience it you should suspect the CDFs or your installation, especially if the buildup occurs in Windows but not outside. My testing has mainly been with Handtools and I can guarantee they are clean! Changes in field definitions in forms are now automatically picked up by reports when resaved after a change. (Previously, fields which were changed in detail were not updated, fields with major changes were deleted. The latter is still true, but fields with minor changes such as length are now updated the next time the report is changed and saved.) The above helps prevent corrupt print out on reports where the length of a field or type of a field has changed and removes the necessity to manually delete a field that has changed in such a way from all reports in which it is referenced - you then had to save the report, reload it, reinsert the field, and save a second time. This was an old, old problem - probably back to 2.x! Extended dates are now validated when entered. Previously, they were translated to a valid date representing the same number of days - e.g. 30/2/1997 would become 2/3/1997. UK SPR# 2017 Date data is now automatically translated when a field is changed from extended to standard and vice versa. On translation fron standard to extended, the century is assumed based on the current settings in the configuration form. On translation from extended to standard, the century is lost. Date comparisons between different date types now work, as do lookups. Century is assumed for standard dates as above. Comparisons are always four digit date - e.g 01/01/2000 and 01/01/1900 are not equal even if the result field is a standard date. Extended dates now appear as correct length on reports. Reports installed or replaced on a network do not lose their data entry forms. SPR#441 FIXES in 5.12 ------------- The following problems have been resolved: Fasttext indices occasionally caused mismatches in certain DQL's.(ones that had an 'any' clause). SPR#4132 Fields that do not appear on a view are not saved when a record is modified (i.e existing data entered by users with full access was deleted). SPR#4126 Slow imports. SPR#4127 Extraneous display when entering first/new record in multiform that contains conditional colors. SPR#4128 Install a procedure failed to copy the procedure's DOS file when on a network SPR#4129 Fix to restore - now capable of restoring greater than 192 files!! SPR#4130 Running a DQL on a view with a filter would GPF when run (not loaded) from the DQL menu. SPR#4122 , UK SPR#1821. When using system relationships or menus with more than 255 forms choices would overwrite. SPR#4123 , UK SPR#1971. Slow CDF loading SPR#4124. Lookups on certain dates would appear , then the field would clear SPR#3455, UK SPR#1953. Certain dates get wrongly translated every 256. SPR#3455, UK SPR#1977. Changes to form properties are lost (453), SPR#3381, UK SPR#1209. Tab Order ignores the first field in a subform SPR#4125, UK SPR#1982 (Note : you must resave your tab order in this version to fix this problem). Compound Indices not recognized by views if the index was created after the view SPR#4077 , UK SPR#1791. Create Index in a DQL will update all of the indexes SPR#4121. Fixes in 5.11 ------------- Views - Crosslinking of RDRR cured. (5.10 only) GPF switching to table view cured. SPR#4115, UK SPR#1937 Non-use of indices cured. SPR#4103 Corruption on resync cured. Can no longer save invalid fields. SPR#4095 Can now clear a record! SPR#4049 Taborder - GPF in form design fixed. SPR#4114 Memory Footprint (16M) - Now meets minimum memory requirements without performance penalty, and clears more memory for CDF's. SPR#s 4107, 4092. Now uses UMB's if available. Color field attribute - No longer needs quotes unless part of a conditional expression. No longer reverts to 'regular' when a field elsewhere on the form is modified. US SPR#s 3663, 4090, UK SPR#1376 Conditional Color Attributes - Fixes to Table view, ctrl-F10, field entry, color bleed and display corruptuion in DQL and record entry. Pre- viously unreli1able in multiforms (Forms which have subforms, or are used as subforms) SPR's 3228, 4018, 4050/1, 4116-9, 4210 Conditional Required Attributes - Previously unreliable in multiforms. 4051 Some valid derivations previously ignored now processed correctly. Conditional DataEntry Attributes - Previously unreliable on multiforms. 4051 Default Records - Erroneous write-back of form definition when deleting default record fixed. SPR#4087 Standard/Extended Dates - can no longer save invalid format. SPR#3449 Alt-T Enhanced Searching - no longer corrupts screen in record entry SPR# 4112, UK SPR#1748 or input using SPR#4113, UK SPR#1811. Create/Delete Index - GPF's cured. Ripple Choice - GPF's on encountering unexpected situations fixed. SPR#3595 GENERAL ISSUES -------------- View Resync. Resychronising a view has been the subject of several bug fixes, but is still somewhat unreliable on large forms. It also has a design flaw in that it is TOO thorough - it resynchronizes EVERYTHING in a view (except field derivation). Our recommendation is to to avoid resynchronisation of views - if the underlying form is changed, you should create a new view and delete the old one. This area is a priority for future attention. Other View information. 1. If you have a View that does not include all the fields on the underlying form, pressing F5 in the view will clear both the fields in the view and the (hidden) fields in the underlying form. However, if you access existing records through the view (by pressing F3, for instance), then change the data on the screen and enter the record, any data in the hidden fields (on the underlying form) are also copied into the new record. But if you modify a record, the 'hidden' data is not changed. This behaviour IS Performs As Designed! 2. If you create a View over a Multiform, the Subforms are not carried over. They must be recreated and redesigned for that View. You may add other subform definitions not extant in the underlying form. 3. If you modify a View and want to save the results under a new name, an additional View will be created over the existing Form. 4. When you create a View, all the relationships possessed by the underlying Form are replicated for the View. The new relationships will retain the original optional relationship names of the owning Form; they must be manually altered for the newly created relationships. 5. It is possible to change the field derivation of a field in a View so that they are different from those of the Form. It is recommended to be cautious when modifying these field attributes as in certain circumstances the data entered from a View could override the restrictions placed in these fields in the underlying Form. 6. Fields that are part of a compound index can be removed from a view once the view is initially saved. Even though this is allowed, we do not advise removing these fields. N.B. for SQL aware users: DataEase Views should not be confused with SQL views. Although DataEase Views perform the same logical function as an SQL view (e.g. a virtual data structure built on underlying real structure(s)), the fundamental structure in DataEase is the form, which includes not just a table definition, but screen layout and methods for data validation, display and lookup, and embedded relations. Therefore DataEase Views cope additionally with these aspects of data representation. General Upgrade Issues 1. The RESTORE function of DataEase 5 for DOS and OS/2 will to allow you to restore DataEase Backups that were made with DataEase 4.x. However, these are NOT converted to DFD 5 format, so you must then sign on to the database using DataEase 5.x and you will be prompted to convert the application to a DataEase 5 application. 2. You cannot restore a DE2.53 database to DataEase 5. Memory Usage under DPMI. When running the 16M product under a DPMI host such as OS/2 or Citrix, Virtual Memory handling (and real memory allocation) is carried out by the host rather than by DataEase. This seems to require more allocated DPMI memory (which is real plus virtual memory - the operating system decides the proportion) than one would expect from usage in other environments. We recommend a minumum of 4MB DPMI allocated to the DataEase DOS session, and this may need to be increased considerably for a large application. The native OS/2 version of the product does not experience this problem. The above is not necessary for Windows, Windows for Workgroups, or Win 9x, as DPMI memory allocation on those hosts is not under user control. However, running a large DataEase application in a Windows session on a machine with limited real memory may result in disk thrashing - increasing real memory or reducing the memory overhead of other active programs is then necessary to restore performance. Under Windows NT and later, DataEase seems unable to use virtual memory. (see compatibility notes). Create Form. 1. If you create a new DQL procedure which uses the command 'Create Form', you will be able to parse and save it, but you will not be able to run it unless you first exit to the Main Menu, then return to the DQL Menu to run it. 2. Problems may be experienced defining and running procedures which create a form, enter records into it, and then delete the form. We recommend you perform these operations in separate procedures, and call them from a Control procedure. We further recommend that, before running them, you save the procedures after creating them, exit the application, and sign back in to run them. Application Name. It is no longer possible to give a Form the same name as the Application name (this is an interoperability issue). Custom Editor. It is not possible to use a Custom Editor to edit a DQL report which has field formats embedded in an "output" statement. Nor should such a report be saved 'incomplete'. DBASE AND PARADOX CONNECTIVITY We no longer support any DataEase Connect drivers, including the dBase and Paradox drivers. If you have real time connectivity requirements we strongly suggest you update to our current product and use the OLE DB or ODBC connectivity they include. You may contimue using your existing DFD application with the OLE DB provider, mentioned in compatibility issues above, as a 'bridge'. Peter J. Tabord