DFD 5.17 README This file documents changes in DataEase since DFD 5.0. 5.17 changes are given first, followed by new features and manual notes. Then there is list of bug fixes up to 5.16, 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. ************IMPORTANT!!! Only DFD 5.15 and later are certified y2k compliant by us! Do NOT use the system locations feature! ************************ For your own protection you should endevour where possible (after your own acceptance testing!) to be on the latest shipping version of product. 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.17 ------------------ DFD 5.17 has been tested with Windows 2000 and Windows XP. 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. Try quick edit off and exclusive mode on. FIXES 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 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'. The memory manager in this version is the latest available, and certifed y2k compliant. The memory strategy has been slightly altered to free as much of 640k as possible for CDF's. Performance improvements have been reported in testing as a result of this change. 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 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 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 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 - OS/2 version now runs in a window. It is recommended that DataEase's mouse support is turned off in this configuration. To do this edit ZTERMDEF.DBZ with a hex editor - set offset 587 to 1. (Remember - if you use debug the offset is increased by a 100) SPR #2787 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. DataEase now installs a utility called HANDLES.EXE. You may use this to check that you have enough file handles available to run DataEase. The number of file handles required is application dependant but should be at least 60. Classic signs of insufficient file handles are the failure of derivations to derive when they should or files failing to be found when known to be present. The utility tells you not the total number of handles available, but the number of handles on the drive from which it is executed in the session in which it is executed - this is important as frequently separate pools of handles are established for network and local drives and for different sessions under a multi-tasking system. To be sure it is best to copy HANDLES into the data directory of your application and run it from there in the environment in which you normally execute DataEase. If you have insufficient handles consult your operating system or network documentation to find out how to increase the value. 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. Virtual memory parameters are now set, like the DOS16M extender parameters, via an environment setting (i.e. the DOS SET command). The environment handle is called 'VMM_DE16M'; the syntax for setting it is: Set VMM_DE16M= where parameter and value may be: SWAPSZ n sets swapfile size to n kbytes SWAPNM sets the name (and path) of swapfile KEEP keeps the swapfile after exiting NOKEEP deletes the swapfile after exiting (default) XSWAP n swapfile limit - leave n kb of disk space unallocated XLOWM n leave n kb of DOS low memory unallocated XEXTM n leave n kb extended memory unallocated The parameters you wish to set must be set in a single command. e.g., to create a 4M swap file named SWAP.DAT in your DE50 directory, and keep it after you exit, type the following: Set VMM_DE16M= SWAPSZ 4096 SWAPNM c:\de50\swap.dat KEEP When creating a new application, do not set your VMM_DE16M parameter to KEEP; doing so will result in an incorrect User Name and Application Name. We recommend you set it to NOKEEP when creating a new database. The SET DOS16M string is now only observed 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.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)! I might be persuaded to introduce a mean calculation of some type for dates if we can all agree on what it 'means'. 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 Note that any reports saved in 5.13 betas prior to build 51307 may now have corrupt print styles. 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. An application can of course use thousands of CDF's as long as not more than 1024 are loaded at once. If you DO manage to exceed this limit (and I don't think you'll manage it!) you'll get a 'can't find CDF' message. WHY CDF LOAD IS SOMETIMES SLOW - In an attempt to optimally implement CDF libraries and to remove the risk of loading libraries multiple times a predecessor of mine took the decision to load a whole CDF library if any one CDF in it was called. So when getting a single library CDF this meant searching the CDF form to identify the other CDF's in that library. This seemed a potential bottleneck to the programmer at the time. So, to speed this up it seemed like a good idea to use indices. Also, to allow an unlimited number of CDF's, the internal structures holding the CDF details were dynamically allocated (although one structure was overlooked, which caused the unwanted effective limit of 255 CDF's ) Unfortunatly, DataEase system forms can't have indices. So the CDF form was, internally, made a 'normal' form. But 'normal' forms aren't cached in memory like system forms. Also, they get full network processing. So, the system form has to be loaded and reinterpreted every time we load a set of CDF's. This plus the fact that indices actually slow searches down when getting a large percentage of a small numbers of records (especially on a network with locking considerations) caused the 'improvement' to have the opposite of the desired effect. Single CDF's - not in libraries - are scarcely affected by this. The smaller the library the less the effect. 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.) This 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 is designed to allow you to restore DataEase Backups that were made with DataEase 4.x software versions into the 4.53r1 format. When you then sign on to the database using DataEase 5.1 for DOS and OS/2, you will be prompted to convert the application to a DataEase 5 application. 2. You cannot restore a DE2.53 database to DataEase 5. You must obtain a copy of DataEase 4x (any version) from your dealer. Special upgrade packs are available in some markets that include a copy of DataEase 4.53. 3. If you have a 15-character User Name, and sign on using the name and password as parameters from the DOS prompt, then your password will be visibly appended to the username on the sign on screen. If you wish to prevent this display, either use a 14-character User Name, or do not include the password in your sign-on command string. Virtual 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 95, 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. Tutorial. The TUTORIAL disk must be installed from the DataEase Install program (as documented). After installing it, you must sign on using DataEase 5 and convert the application. The User Name is 'NEWUSER'; the Password is 'TUTOR'. 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 The following issues occur when using the dBase and Paradox drivers. Form Definition. When you define a DataEase numeric string field over a dBase text field, DataEase does not display padded zeros regardless of whether you selected this option in the DataEase Application Configuration. DataEase allows for a time field to be defined over a dBase or Paradox character field. This is not recommended. A DataEase numeric string field over a Paradox date field will cause a "type mismatch" error if you add a record and then switch to table view in record entry. Use DataEase date fields over Paradox date fields. Record Entry. It is recommended that all remote tables have a unique key field. This is because access is via an SQL interface, and SQL posesses the following limitations when no unique field is provided: 1. Searches will retrieve multiple matches in a random order. 2. If you have duplicate records, all of them will be deleted if you delete one. Peter J. Tabord