[Firebird-net-provider] NULL Parameter values for textual data-types / Encoding questions

[Jojakim S. <JS...@de...>]

I have a question regarding the FirebirdSql.Data.NGDS.GDS.FixNull(XSQLVAR
xsqlvar) method:

When executing a statement with an input parameter of value DBNull and type
FbType.VarChar or FbType.Char the FixNull function sets up (as I understand
it) a dummy (null) value which is transfered to the server. The actual
indication that the parameter is DBNull is done by setting xsqlvar.sqlind
= -1.

		private void FixNull(XSQLVAR xsqlvar)
		{
			if ((xsqlvar.sqlind == -1) && (xsqlvar.sqldata == null))
			{
				switch (xsqlvar.sqltype & ~1)
				{
					case SQL_TEXT:
						xsqlvar.sqldata = new byte[xsqlvar.sqllen];
						break;

					case SQL_VARYING:
						xsqlvar.sqldata = new byte[0];
						break;

Why now in FixNull the dummy value used for SQL_TEXT and SQL_VARYING are
arrays of bytes? and not strings? As in WriteSQLDatum the xsqlvar.sqldata
value is cast to a string, an exception is the result.

I did a quick-test and assigned xsqlvar.sqldata = string.Empty in the
SQL_VARYING case, and all seems to work well now.

But I'm not sure for the SQL_TEXT case. Is it required to always write the
exact amount of bytes for a CHAR column? What about a column with
UNICODE_FSS encoding: Do I have to write the amount of charachters declared
in the table creation statement, or the amount of octets reserved for the
column (for UNICODE_FSS this is 3 times the declared value).

If the latter is the case, I think the way how WriteSQLDatum works isn't
correct, too:

case SQL_TEXT:
	if(((string)sqldata).Length != xsqlvar.sqllen)
	{
		throw new GDSException(isc_rec_size_err);
	}
	db.output.WriteOpaque(
			Encoding.Default.GetBytes((string)sqldata),
			xsqlvar.sqllen);
	break;

case SQL_VARYING:
	if(((string)sqldata).Length > xsqlvar.sqllen)
	{
		throw new GDSException(isc_rec_size_err);
	}
	db.output.WriteInt(((string)sqldata).Length);
	db.output.WriteOpaque(
			Encoding.Default.GetBytes((string)sqldata),
			((string)sqldata).Length);
	break;

While debugging I found that xsqlvar.sqllen contains the amnout of octets
reserved for the columns data, for textual columns of UNICODE_FSS encoding
this is 3 times the declared charachter amount. So comparing
((string)sqldata).Length with xsqlvar.sqllen as a condition to generate
exceptions isn't correct.

Aswell, just writing out the bytes that result from
Encoding.Default.GetBytes() is not correct because a string with just 10
ascii chars in the range 0 to 127 results in a byte array of length 10. But
for the SQL_TEXT case WriteOpaque is directed to write out 30 bytes.

For the SQL_VARYING case, if you write a unicode char with a UTF-8 mapping
of 3 bytes, you only write 1 byte, as string.Length will return 1.

Another thing is, that the usage of Encoding.Default should be replaced by
Encodings.GetFromFirebirdEncoding(connection.Charset).

So the key points are:
- When outputting a string, is it neccessary to output the amount of
charachters or the amout of bytes the string needs in the connections
encoding?
- Use the correct encoding!
- Remove inconsistencies within the type of data stored in xsqlvar.sqldata
for textual data types. Current State: ReadSQLDatum uses the byte[] version,
byte[] to string conversion is done in FbResultSet. WriteSQLDatum expects
strings. FixNull requires WriteSQLDatum to expect byte[].

Excuse the long message. Any comments welcome. I would take the time to
correct the behavior after an agreement on the what-is-correct is found.

Thanx,
  Joja