Don't use SqlRecord in EGL Web Service

Here is a general rule: When designing a SOAP web service with EGL, do not use an SqlRecord as a parameter or a return value.

"Why not?" you might ask. Good question. It takes a wee bit of explanation.

Typically, an EGL-generated SqlRecord looks something like this:

dataitem K FLOAT end

dataitem D DATE end

record T type sqlRecord {

        tablenames=[["S.T"]],

        keyItems=[K]

    }

    K K {column="S.T.K"};

    D D {column="S.T.D", isSqlNullable=yes};

end

Since the D column was defined in SQL without the "not null" clause, the EGL wizard adds the "isSqlNullable=yes" attribute.

Although the attribute says "isSqlNullable=yes", the date field is not actually nullable in EGL. And "EGL nullable" affects the null'ability of a field for a SOAP web service. The type should have been defined as D? instead of D. It's a problem with the wizard that generates the EGL code. You might not have the same problem with a hand-coded SqlRecord. (But, who does that?)

Let's say D=null in the client. If you use an SqlRecord as a parameter, D is replaced with today's date on the server side because, without a question mark, it cannot be null.

Let's say D=null in the server. If you use an SqlRecord as a return value, D is replaced with today's date on the client side because, without the question mark, it cannot be null.

Fortunately, there is a relatively easy work-around. Look for the corresponding "search" record. A "search" record is a BasicRecord, not an SqlRecord. Typically, an EGL-generated "search" record is defined in the same source file and looks something like this:

record TSearch

    K K?;

    D D?;

end

When D=null as a parameter, it will be null on the server side. When D=null as a return type, it will be null on the client side.

Because so many SQL tables have a date column and because an SqlRecord is slightly slower in a web service request/response than a BasicRecord, it might better not to use SqlRecord in this case.