When adding an unbound field to a Dynamics SL form for a VBA screen customization it’s pretty common to see System Message 5005, “Unable to locate field … in table b…. Error in property of control Form1.x….” Fill in the field name, table name and control name where the ellipsis appear above.

Most customized controls in a VBA customization only have two numbers in the fieldname property, so it’s easy to follow suit for the unbound control. That’s the problem. An unbound control needs all three numbers in what the documentation calls the TableNameStr argument; the offset, type, and length.

It uses the example of the physical table Account, for which the first column is Acct, a ten character string. For this post we’ll use “bUnbound” for the buffer variable for a type without a corresponding table named “Unbound”. In a VBA customization these are usually defined in a separate code module and could look like this:

Type Unbound
Acct As String * 10
End Type
Public bUnbound As Unbound, nUnbound As Unbound

Then the buffer is usually allocated and linked to the controls in the Form1_Load event by:

Call VBA_SetAddr(“bUnbound”, bUnbound, nUnbound, LenB(bUnbound))

The documentation then says (switching their buffer name for ours) “After the VBA_SetAddr call in the above example, SWIM would know that the first byte of bUnbound is at a particular location in memory, hereafter referred to as location M, and furthermore that the first byte of bUnbound.Acct is offset zero bytes from location M as well as the fact that Acct is ten bytes long.”

The documentation here refers to the first and third numbers, the offset and the field length. The second number in the fieldname property is the data type, which is zero for a string. The Dynamics SL Kernel, SWIM, knows these values when there is a physical database table.

Later, the documentation notes “Usage of an unbound control is the only case where the developer must fill in the detailed field information manually since it will not exist in the SQL data dictionary.”

Again, it’s easy to overlook this and mimic the way other fields with physical tables are listed in the customization when they are modified, generally when they are moved or the tabindex property changed. Typically they only have the first two numbers of the FieldName property: the position where the field starts (the offset) and the data type.

With a physical table, it would be OK to have:

fieldname = “”bAccount.Acct”;0;0″

But with an unbound field you’ll see System Message 5005 if you try that:

fieldname = “bUnbound.Acct”;0;0″

You must include the field length:

fieldname = “”bUnbound.Acct”;0;0;10″

A simple solution, but following the lead of an exported customization has led a fair number of developers, including me, to sometimes create an empty physical table in the database to let SWIM work its magic, when all that was needed was the third number.