| Bottom | Unframe | Help |

Locate in Contents | (framed)

Locate in Discussion | (framed) 

XFormDBF error #112
Mapping expression is incompatible with field type.
Field: OWNERPLUS4, type: C requires expr type(s): CM, but mapping yields type: L

Further testing and analysis shows that similar problems would occur for any field type other than Logical.

To fix the problem, some additional logic in the XFormDBF.XFOM_ValidMapping method could force a literal NULL to be treated as being of the required type.  Doing this in a rigorously correct manner may a bit awkward, but not too difficult.  The trick is to precede the evaluation with a case statement that casts the local result variable into the desired data type.

This somewhat obscure bug is due to the subtleties of VFP's treatment of NULL values, which may or may not have a data type.  VFP's syntax has no literal representation of NULL that casts it into an explicit type.  However, the following simple expressions can be used to create explicitly typed NULL values:

• val(null) -> NULL (Numeric)
• substr(null,1) -> NULL (Character)

Presumably, with a little experimentation, one could construct other simple expressions to produce any desired type of NULL.  This workaround avoids the imperative need for any programming changes to fix this bug.  I.e., instead of specifying a literal NULL, you can simply substitute one of the above typed NULL expressions.  (XFormDBF Help documentation really should mention this unless/until the program logic fixed.)

Also consider switching from textboxes to editboxes, for greater convenience in scrolling through long expressions.

Nayda brought this up in her ErrHandler forum posting of 1/26/01, and I mentioned these further details in my reply:

Instead of causing the Run to stop, a "tracing" message would be issued (via ehm_showapperr) with information about the offending record. Presumably you'd also want to report a count of such non-fatal errors that occurred in the last run, and you would want this feature to be optional, possibly on a per-config basis. There's also the question of whether to consider the overall run a success or failure when this number is non-zero.

Nadya again mentioned (via email of 5/23/01) the need for defining "show-stopper" vs ignorable (but logged) errors in XFormDBF, i.e. Numeric Overflow cases.

Another benefit of substituting a grid in place of a listbox is that it would make it easier to eliminate the bug causing "String too long" for mapping expr > 254 chars, which arises from an undocumented VFP Listbox limit.

Note that it would be helpful to switch to a grid-based implementation of the mapping display before attempting to add any more columns of information to the present listbox-based design.

This feature addresses Nancy's request of 10/31/00, and her email of 11/1 which included the following snippet of code from her modified version of the xformdbf.Unload event:

IF type('ojc')="O" and type('oJC.curAppStat')='C'
    IF NOT this.ehp_success
        oJC.curAppStat='I'
    ELSE
        oJC.curAppStat='C'
    ENDIF
ENDIF

dodefault()

Instead of wiring this logic directly into XFormDBF, I would propose to create a small UDF, xfunload.prg, from the preceding IF statement, and adjust the logic to take an object reference argument to be used in place of "this".  The tie-in to XFormDBF would then be accomplished by assigning the command line "xfunload(this)" to property xformdbf.xfop_unloadcmd.

In the long run, switching from listbox to grid-based mappings on the Fields page would give us more options for cleaner solutions to this problem.

In XformDBF.Xform_OpenOutPut try put this line:
* connect output table to its grid and listbox
thisform.pageframe1.PageFiles.grdOutput.recordsource = ''
before
thisform.pageframe1.PageFiles.grdOutput.recordsource = STDB_ALOUT

I.e., assign an empty string to the grid's recordsource property before assigning a non-empty value.  I'll have to give this a try to see if it works as a quick fix.  Nadya also suggested looking at her wgGrid.FormatAndSetCaption method, which I believe has to do with a different way of determining the default column widths.  I would view that as a separate problem, probably of less importance than the general ability to save and restore the user's grid arrangement, mentioned previously.

REPLACE cmdline with STRTRAN(STRTRAN(cmdline, "savrp_", "svp_"), "m.cmdr_arg1.parent", "m.cmdr_arg1") ALL

Preliminary conversion notes will serve as a guide to this change, and these notes will be further refined after going through the XFormDBF conversion.  A similar conversion will also be desirable for BTCrit, and the same notes should be helpful in doing that task.

• directly editable Input and Output file text boxes
• simplify editing of Template file specification

Note that these changes only affect xformdbf.app and xformdbf.chm (the Help file), which should also be updated in the mdacomm directory.  If you converted your configuration meta-files as directed for the previous update, you don't have to do it again.  If you still have old meta-files that pre-date those changes, you should perform the meta-file conversion I mentioned previously.

REPLACE cmdline WITH strtran(cmdline, 'D:\REDP\APPL\', '..\') FOR inlist(seq, 510, 600, 5120)

These sequence numbers correspond to XFormDBF's state restoration steps for the Input (510), Template (600), and Output (5120) file specifications.

• dynamic status bar message for input grid on the Fields page
• display current/max record # in status bar for Files page grids
• fix spurious incompatibility msgs for placeholder mappings

Note that these changes only affect xformdbf.app, which should also be updated in the mdacomm directory.  If you converted your configuration meta-files as directed for the last update, you don't have to do it again.  If you still have old meta-files that pre-date those changes, you should perform the meta-file conversion I mentioned previously.

• allow input data to be seen from the Fields page
  Note that this requires a conversion step to be run again old configurations in the meta-file.
• support a single field Test operation
• update XFormDBF help to reflect recent interface changes

• allow input data to be seen from the Fields page
• support a single field Test operation

Also adjust the Help Contents include file to add more bookmarks.  Rebuild the compiled HTML Help file (xformdbf.chm) to pick up all of the latest edits.

Since you can't do a Save As... from the VFP table designer, an additional button to handle the Save As function might also be useful, but treat this as a separate task.  This would make it easier to create a new template output structure derived from a previous one (which could be considered as the template template).

The subject of a Modify Template Structure pushbutton was previously mentioned as a low priority issue in the old XFormDBF task list (from Nancy's suggestion of 1/14/00), and Nadya brought it up again in email of 5/11/00.  Most recently, Nadya raised the issue again in her forum posting of 3/1/01, so this now seems to warrant a higher priority.

do ..\tablemaintenance\tablemaintenance with 'Manual','Lookups'

On 4/22 and 4/28 Nadya suggested setting the default to use of her TableMaintenance application.  (I would have to confirm the correctness of the above command line with Nadya before making this change in the xformdbf.h include file.)  However, the macro approach makes life easier only if this is a stable generic setting.  Otherwise, we may as well not rely on an absolute default, and instead use the more flexible global memory variable approach.

Alan originally assigned this task a high priority.  But in our subsequent discussion on 10/4/00, we agreed that it will suffice to use the recommended approach of assigning a value to global memory variable m.xfor_lkup, which avoids the need for any XFormDBF macro changes.

This topic came up again in email from Nancy of 5/31/01, to which I replied on 6/1.  Nadya agreed in her reply of 6/4 that this macro change should not be necessary.

Nadya's message of 1/26/01 also suggests the possibility of using Nick Neklioudov's Grid Highlighter.  This would require further research.

Discussion

DELETE FOR 'Splitcon_2_1' $ cmdline

Also see these related tasks:

• support a way to set minimum sizes for sub-containers
• support a single field Test operation
• update XFormDBF help to reflect recent interface changes
• optional inclusion of field attributes in column headers
• improve highlighting of the current record(s)
• support optional browse windows for input/output tables

As a specific example, in her email of 4/22/00 Nadya asked for the ability to print mappings expression one or all FunctionIDs.

In Nadya's forum posting of 1/4/01 she suggested providing a Print capability for each page of the form, e.g. for the output structure and mapping information on the Fields page.  Limiting the report to the current configuration would be a reasonable simplification to consider as a starting point.

I did a bunch of further testing and standalone benchmarking during April, 2001, which indicated that the most serious performance problems on the BT system were attributable to the networked setup for the sample configurations we analyzed at the time.  It should be noted that XFormDBF performance may be greatly enhanced by running against local input, output, lookup, and configuration files.

In her email of 6/27/01, Nadya also mentioned this, which will require further clarification:

"XFormDBF slowness during Conversion job. XFormDBF was mostly tested in Extracts job, where it performs with reasonable speed. Tanya has several complaints regarding GUI and performance of XForm in Parcel Conversion job. She needs to describe all problems in the appropriate Forum http://www.ideaxchg.com/ix08/d1/0000004a.htm ..."

After my conversation of 6/23/00 with Alan, I tentatively upped the priority of this task, although Alan's previous posting had assigned a lower priority.  Alan had assigned a higher priority to another task relating to the Lookup button (on the main form), which should not be confused with the new Funcs button that will go on the Fields page.  Discuss this again with Alan for further clarification.

Based on further discussions with Nadya on 8/23, this task no longer appears to be important, because she can easily incorporate "function library" features within her Table Lookups facility without any further complications to XFormDBF.

• Q189453 - HOWTO Prepare HTML Help Files for Context-Sensitive Help
• Q188444 - BUG Editing MAP or ALIAS in the HTML Help Workshop Causes Error
• Q195613 - HOWTO Create a Simple Context-Sensitive HTML Help File

• XFormDBF Forum
  for TOC pages and system pages in ix07, the edited portion of the VFPUtils web.
• XFormDBF Help
  for pages included into the HTML Help file, also in ix07.
• XFormDBF Discussion
  for messages, Threads TOC, and discussion-specific system Search/Post/Confirmation pages.

Let this task be superseded by the revised definition of xfma0020: refinements to categorization of tasks.  Also see vmma0008: show date done for each entry in the outline of completed tasks.  (Generic task management issues really belong in the VFPUtils Misc or IdeaXchg task lists.)