4.622 Updates

2010

The version included in the download for 4.622 since 31/10/2007 could terminate with a memory exception or send an invalid reply to tcpw.w32 in certain circumstances.

2009

The Windows installation guide included in the download for 4.622 has been updated to the latest version, to alert customers to the fact that DP4 4.622 does not work on 64-bit versions of Windows.

2008

The DP4 SQL interface did not handle unterminated strings correctly, and gave a spurious error message.

Under certain very rare circumstances fetch() functions might return the wrong record when accessing databases that used 4.620 or legacy database format. The problem was more likely to occur with legacy databases. Databases using the new "Two file index" were unaffected.

The install program has been updated to make installation from within WinZip work better on machines for which the TEMP folder name is long.

2007

The fix posted on 31 Oct could cause spurious network failures with additional error code 270 under some circumstances.

PROGPRN was prone to GPFs when printing large programs.

Under certain circumstances TCPMGR leaked handles when very heavily loaded. The fix is dated 12 October but was not released until 31 Oct

Neither dynaback -copy for dbrecov worked correctly when either the DAT,IND, or PTR file exceeded 4GB. dynaback would fail reporting the original database corrupt when it was not. dbrecov would appear to succeed but leave the database seriously corrupted. This bug was caused by a fault in the large file support built into trmw32.dll.

Under certain, very rare, circumstances databases that use the new "Two File Index" structure may develop a corruption in the index which causes dbcheck -full or dynaback to fail. The corruption is real but usually harmless, except for the fact that it may problems because of the need to restore the last backup. The updated dbmslibt.dll (dated 15/03/2007 internally) fixes this problem, but if a database is already suffering from it it should be reorganised. Normally it should not be necessary to use the -corrupt command tail in this case.

On certain computers running Windows XP,2003,and (probably) Vista, DP4 applications that fail during initialisation were unable to report errors interactively. The update contains a work-around for a "feature" in these versions of windows that affects applications that use manifests to indicate support for XP style user interface. On these platforms such applications may have to had called InitCommonControls() before using MessageBox(). Whether or not this problem manifests itself seems to depend on the service pack level and update history.

2006

Re-issue of fix made on 8th June. The released file did not have a version stamp.

On Windows NT family operating systems when DP4 is run as a service, then DP4 would hang when DP4 errlog logging is loaded, after there has been a logoff/logon sequence on the main desktop while the service is running. How long the hang would take to occur would depend on the volume of diagnostics being produced. This bug is long standing, but so far is fixed only in 4.621a and beyond.

When updating data over a network connection network errors were occasionally reported as System Error 7 errors, instead of as Fail Error 7 errors. This fix was made on 25th August but has only now been issued.

Pressing G to display Global variables also caused program to run as far as next breakpoint. Pressing G now works like D and L options - i.e. it displays variables without changing program state.

dp4_bf_fetch() did not automatically set the DEPTH flag when a non-zero value was specified for the final parameter. This would have caused unexpected behaviour in C++ programs that used this functionality. Also dp4_blk_f2nd() passed the depth parameter incorrectly in all cases.

Install program did not work properly if you tried installing additional products after a clean install. Install program did not work properly if you tried installing over an installation with a broken [preload] section. Unnecessary warnings about rebooting have been removed.

Embedded data was not working correctly in controls containing more than one item of embedded data. This bug was introduced by the fix issued on 19th October 2005.

The 4.623 beta ZIP file, now available from the DP4 FTP site contains enhanced versions of srvw32.exe and syslibt.dll which together can help solve problems caused by ill-behaved programs that terminate without allowing DP4 to perform necessary clean-up. The new version of syslibt.dll will not run on Windows 95. For details see information on the new dp4.ini setting monitor.

If one or more programs updated the database while dynaback -copy was running against a database, but at the moment dynaback -copy completes no other programs has the database open, or no further programs updated the database before it was finally closed, then the database was not properly closed and dbrecov would restore it from the backup that had just completed because no rollback file exists.

In some circumstances dynaback -copy would fail because of a checksum error in the backup. In theory this bug could also cause dbrecov to leave a database in a state where it would fail dbcheck because of an incorrect hole.See a4000034.htm for details of this bug. This bug is present in all DP4 releases

This bug also contains a patch for a minor bug that arises with Legacy and 4.620 style databases. In 4.622 only adjacent holes were not always merged when this was possible.

The new dbmslibt.dll also attempts to work-around a bug in the Windows API MoveFile() which cause an attempt to rename a file to fail for no valid reason.dbmslibt.dll now retries renames ten times if certain error codes are returned by the operating system. This bug could cause reorgdb, numbsys or dynaback to fail at the very end. the bug is extremely intermittent and does not occur at all on most machines.

Extremely large transactions (of the order of thousands of posts with no commit) could cause a GPF in dp4srvr.w32.

In some circumstances DYNABACK -COPY did not apply the rollback log to a backed up database. This caused the DBCHECK to fail, and hence the original database to be marked as having problems when in fact it was OK.

If a system failure occured while DBRECOV was applying a transaction log then a subsequent DBRECOV might fail to apply the rollback log created by the first DBRECOV, leaving the database corrupt

Extremely large transactions (of the order of thousands of posts with no commit) could cause a GPF in dp4srvr.w32.

After map_copy(), or show_attach_map() into an edit control with a prompt box the screen was not updated correctly, especially if "fully buffered" was not selected as screen refresh mode in DFSETUP.

Fix for a bug in Enumeration Controls which caused spurious map not found errors. The fix has also been applied to 4.621a

Due to a bug in DeferWindowPos() trmw32.dll leaked "user objects" in some circumstances. If a program ran for a very long time this could cause resource starvation, leading to a GPF when trmw32.dll could no longer create windows. A work-around has been added which has been enabled by default. See a4000035 for further details. All 4.6xx releases of DP4 for Windows are affected by this bug, but the fix has only been applied to releases 4.622 and 4.621a

2005

4.620 or legacy databases could be left in a state where DBCHECK failed even though the database appeared to (and does) work perfectly. This was caused by an unused pointer being left uninitialised. Generally the pointer was give the correct value (0), but very occasionally it could be set to an invalid value.

reorgdb could create a database with duplicate primary keys if a legacy or 4.620 compatible database was reorganised after a structure change that results in a primary key change

shutdown -db dbname -nowait could cause DP4SRVR to GPF in some circumstances

Database could be corrupted when record locking was used. See a4000034.htm for details of this bug.

The -silent option failed if the database needed to be restored from the last online backup.

Re-issue of fix posted on 25th November - the CE files did not load as they were linked with an incorrectly built set of DP4 libraries

The various patches to these utilities issued earlier this month for the Windows version of DP4 have now also been applied to Windows CE. This was originally issued on 22nd, but the 2nd November fix to REORGDB was not in fact present as that fix had been posted with an incorrect build number.

Re-issue of fix posted on 18th November - the original fix introduced a nother spurious corruption report

Spurious corruptions could be reported on databases using enhanced index compression if character keyfields contained null terminated strings rather than blank padded data.

The print out for corruptions was incorrect for databases using BCD based number systems.

The quick restore facility in dbrecov.exe was afflicted by the same bug as was fixed in dbrestor.exe on Nov 9th

If a record was locked before the database was updated the data file checksum became corrupted, causing dbcheck to fail subsequently. Also, if there was a system crash at such a point it would be possible for records to be left locked on the database.

The options that should apply the transaction log no longer worked. They returned immediately without issuing any warning message, creating the impresion that they had worked, but did not actually apply the log file.

The fix posted on 19th October introduced a new bug, which could cause maps that used embedded data to GPF, especially if they were used repeatedly in a scrolling map.

Option 1 still reported spurious errors when reorganising older legacy structure databases that had not previously been reorganised with release 4.622

The files issued on 11 August were reported as corrupt by progdate, so have been rebuilt and re-issued. There are no changes to the source code.

Would occasionally GPF on Windows 2000 for no apparent reason. This problem arose because an internal validation performed on a Window handle was not correct on Windows 2000. The validation concerned has been present in trmw32.dll for many years, so the problem exists in all 4.6xx releases of trmw32.dll. The validation has been removed because it depended on undocumented information that is no longer valid:

• trmw32.dll assumed that the high order word of a window handle was never -1 since this value is used for various "special" values such as HWND_TOPMOST. However, in Windows 2000, ordinary window handles do sometimes have this value in the high order word. As far as I know this is not the case on any other version of Windows. However there is no guarantee, so the GPF might also occur on other platforms.

Did not support the version Tab in Windows Explorer.

syslibnt.dll reported a spurious error if a preload section of dp4.ini is used when the DP4 service is started.

If DP4 was loaded in the named connection configuration, and a very large number of programs were running locally, and the DP4 service was stopped then tcpmgr.w32 might continue to run for a considerable period (roughly two seconds per local program), after the DP4 service stopped. The fix for this problem means that once a DP4 ipc channel has failed for a process (because there is no server for the channel), all subsequent calls from that process to IPC functions using that channel are instantly failed. Previously calls were always attempted, and there was a one second timeout until the server status was checked and the call failed.

The option to force a scale factor on type N fields did not work in any 32 bit release of DP4 when the field was in string format. The value of the field was always set to 0.

dp4srvr did not behave correctly after a system error 87. Any operation using that database returned system error 87, including an attempt to close the database. This meant that the database could not be recovered from a backup until the DP4 service was stopped and restarted.

Calls to the DP4 terminal manager no longer returned the correct exit code in the event of a system or fail error internal to the terminal manager. These calls should return error code 3 or 4. Instead error code 2 was being returned. This bug has been present since 4.620

dp4.exe did not exit cleanly after a DP4 IPC error, nor recover cleanly if a system error 87 was reported on a database, nor behave correctly on a second or subsequent system or fail error of any type. This bug has been present since 4.620.

dbmslibt.dll is more or less identical to the file issued on 1 Aug, but has now also been issued for Windows CE. The Windows file has been re-released because the 1 Aug file had an incorrect internal version number.

The change made on 2nd August caused a corruption in the index for exactly one record which does not become apparent until more records are added to the database.

Column functions did not respect the precision of N fields.

The CHAR function did not convert dates correctly : the last two digits of the year did not appear.

The change made on 14th July could cause option 1 of REORGDB to fail with a spurious illegal length message.

The messages produced have been improved. The utility has also been updated to support reversion to 4.622 from 4.623.

The changes of 14th July caused a spurious systemerror 87 when MAKEDB was used to change a database. This fix has not yet been applied to the Windows CE DP4 software.

Various enhancements from previous 4.623 beta have now been incorporated into 4.622 as follows:

• DFPRINT supports printing of multiple copies
• Global variable QPR_DEVICE added to QAB to enable programmatic selection of a printer. Must be set prior to a "device select" procedure that specified DEFAULT_PRINTER as the chosen print device.
• name and location of userdata.sys file can now be specified in dp4.ini on a per-program basis. Also hide_empty_buttons setting.

The documentation will be updated shortly to reflect the fact that these changes are now in 4.622

• If DBRECOV invoked the quick restore option because rollback recovery failed, then it failed to restore the PTR and DCI file from a two file index database. This would cause the database to be corrupted, possibly very seriously. Less seriously it also did not attempt to recover the database if these two files had been deleted but the index was marked as OK. This fix has necessitated a system database changes for additional error messages.
• The version of dbcheck supporting the -full option has now been added to the 4.622 download, and this option is now used by dynaback -copy

Fixes for two bugs related to data independence:

• REORGDB crashed or hung when indexing tables if a change to the key structure meant that one or more records had to be deleted.
• dbmslibt.dll returned timestamp information incorrectly when data independence was needed to return data from a table that is compressed. In the database manager this could result in spurious contention errors, or in a contention error not being generated when it should be.

The -server_name command tail did not work in sql.exe. Changes to both tcpw.w32 and sqllibt.dll were needed for it to do so. Both of these changes have also been added to 4.621a

Fix for GPF that occurred when an error occurred while opening the database or connecting to the server. Also -server_name command tail did not work. The latter bug is in 4.621, but has not been fixed there. The 4.622 file is compatible with 4.621

Fix for GPF that occurred when adding a control to a map for which the frame control used a font that was not set to be the default font for the map. This bug is also in earlier MAPEDIT releases. The fix has been added to the 4.621a set but not the base 4.621 set.

The structure transfer option could cause a memory corruption which might cause a GPF, but which might cause RECASTDB to terminate without any error messages. This might cause a user to believe the structure transfer had completed successfully when it had not.

The count of users with programs that were updating the database was no longer being maintained correctly. In some circumstances this could cause the log file to be closed when it should not have been. This could cause changes to be lost if a dbrecov was required, and in addition could have a severe impact on performance. This bug did not occur in earlier releases.

Typing ahead into a character field could cause the display of the field to be corrupted, and typed characters to be unexpectedly lost. This bug is also in earlier releases but has not been fixed except in 4.621a.

Did not handle numeric fields with units correctly when printing 4.500 maps.

If a network error occurred at a certain point tcpmgr might become less responsive. If only one user were connected then it might become completely unresponsive.

The CE version of tcpmgr would sometimes stop processing requests and use up all available CPU if the -nokeepalive option was in use and a remote client disconnected and immediately reconnected.

This program has been added to the Windows CE set.

The data file checksum could be incorrect after running dbrecov for databases using one of the new database structures introduced in release 4.622. This could happen if a hole that was formed by deleting two or more adjacent records was partially re-used and then rolled back to its original state.

The trm_run_program() function, (used by run another program" QAB procedures), did not handle program names in quotes correctly. (This bug is also in previous releases but has only been fixed in 4.622)

The synchronise facility did not work correctly when a field was updated in the record being transferred. Changes were not committed correctly, so that a record could be marked as being synchronised when it had not been.

The CE version of tcpmgr would sometimes stop processing requests and use up all available CPU when more than one client is active.

The CE version of tcpw would sometimes refused to allow programs to connect. This is caused by a bug in the Windows CE version of the connect() API.

tcpmgr no longer reliably shut down in a timely manner if the DP4 service was stopped while there were very many active clients. This bug was introduced in 4.622

tcpmgr might refuse to accept new connections because it believed the maximum number of connections had been reached, when in fact some of the connected sessions were dead but had not been cleaned up because tcpmgr was busy. This bug also meant that more than one session to the same machine could appear in the network manager display.

Two changes have been made to avoid problems that can occur if the DP4 service is stopped and restarted, but applications that used the previous instance of the DP4 service do not terminate.

• Applications using trmw32.dll would fail to start if another application had left temporary files open. Now trmw32.dll will use a different temporary file name if it cannot open a temporary file with the desired name.
• syslibt.dll will not permit applications to connect to a different instance of the DP4 service from the one they were originally connected to. If an application tries to do this it will always get an IPC error.

These changes were issued on 31st March, but not documented until 4th April.

If a fail 9 error is returned to tcpw.w32 from a server (indicating that there is problem in IPC between tcpmgr.w32 and dp4srvr.w32 on the server) tcpw.w32 now changes the error to fail error 15.

This change was issued on 14th March, but not documented until 4th April.

dp4srvr.w32 now handles any exceptions (GPFs) it generates. If an exception arises dp4srvr.w32 will terminate and broadcase a message to shut down the DP4 service and applications. If you want the Default Windows handling of exceptions (to produce a Dr Watson log for example), you can disable the new exception handler by putting catch_exceptions=0 in the [dp4srvr] section of dp4.ini.

This change has been made to address the issue discussed in a4000028 (Dr Watson can cause 4.62x DP4 to hang).

There are several new enhancements to MAPEDIT which make it easier to use:

• When you save a map you will be warned if you have used the same mnemonic on two different controls
• An asterisk is placed at the end of the document title for any maps you are editing that have unsaved changes.
• There are several new accelerators that allow you to bypass the menu for common commands:
  • Ctrl+B to open a database
  • Ctrl+M to open a mapset
  • Ctrl+S to save the map being edited
  • Ctrl+A to open the save as dialog
  • Ctrl+E to save all changed maps

There is also a minor bug fix: If a map contained two controls with the same field number and in the same place and the same size, MAPEDIT would previously swap the order of the controls within the map each time you edited it. This could cause problems when posting translator format map files.

Added new DP4.INI setting no_auto_close to prevent Windows CE.NET from shutting down DP4 whenever it feels like it.

The find fields in procedures facility now displays the table name for database fields if more than one table may be matched.

A new CE set is available, built with the "ArmV4" processor option. This set of programs is designed for Intel XScale devices configured as ARM type devices running CE.NET 4.2 or later.

The new CE programs fix a bug in TRMWCE.DLL. Previously the %document option supported by QAB and DP4 menu programs did not work on Windows CE.

The .SQL files used by SQLMAKE for customising datatypes and names changes are now included in the installation of the ODBC Gateway. An alternative version of dtypes.sql mssqltyp.sql is supplied which may be more useful than the default dtypes.sql if you are creating a Microsoft SQL Server database.

New function map_get_metrics() added to C library. Finds adjusted height of map after rows and columns added for border and title and, if MPM_PRINT flag specified, after adjusting height of rows for specified print x and y factor.

progrund.exe did not correctly display rolenames for tables and fields
progmake.exe now displays (part 1 of n) for entry conditions in program flow diagram.

An enhancement to printing is included in 4.622 which gives better results when printing maps containing boxed (and hence widely vertically spaced) edit controls to legacy print devices. See e4000048 for details, but do not use the download there.

SQLEXE will now create XML format output if you supply -xml command tail. The output is created with a .XSLT stylesheet that formats the output as a quite elegant HTML table. (See Example)

It should be noted that this style of output only works in some browsers (Internet Explorer 6, and current Mozilla/Firefox are known to work, Opera 7 and Internet Explorer 5.5 are known not to work). Normally you would convert the XML to HTML on the server. (This is quite easy, at least on machines with Internet Explorer 6 installed.)

By editing the SQLEXE.XSL file and the SITE.CSS file you can modify the appearance of the output.

See the updated documentation for UNLOAD for ways to control the element names used in the XML output. (This documentation will shortly be moved to a more sensible place)

UNLOAD can now create XML files. See the updated UNLOAD entry in the DP4 Quick Reference.

After using either of the "Compiled Changed Programs" options from within PROGMAKE, subsequent changes would not necessarily flag the programs as needing recompilation again. Note that a similar bug still remains - if you compile just the program being edited then this program will not necessarily be marked again as needing recompilation if you continue to edit the program.

Summary information for compilation changed: Compiled Ok count now only includes programs that compiled with no warnings or errors. Programs that compiled with warnings or errors are shown separately next to "Compiled with warnings".

Network table structure in dictionary did not match real use of table. This bug is long-standing but of little importance. The fixnet program (supplied with all DP4 releases) can be used to correct this.

New Enhancement. Change to behaviour of EQUAL search incorporated into release 4.622.

New Enhancement. QAB User Interface Enhancements incorporated into release 4.622.