Subject | Re: [IBO] Strange Data in my inserts |
---|---|
Author | Geoff Worboys |
Post date | 2001-03-15T22:41:52Z |
Hi Colin,
itself will detect the null fields and give you an error. If
CheckRequired is false, the null fields will get through to the server
and the error will come from there.
these will be applied to inserted records, but defaults defined at the
server will not be used unless the field itself is NOT part of the
insert.
really there (so it is not a monitor bug :-)
How do you select the record for update? That is; Firstly where do
you get your key value from. Secondly I do not see the
select/retrieve of the row to be edited in the monitor output - you
can turn on the Row option of the monitor to see individual rows
returned from the server. This should demonstrate whether the rows
are being returned with these strange characters.
Perhaps you can see the curious logic here. If the problem is
happening on update, then the NOT NULL fields must have contained
something originally. So that data should be returned when the record
was selected for update. So either the row was updated by your
processing OR the row contained the strange data to begin with.
You say you are reading from file, is this an external table defined
to Interbase or is it truly just a file? (The "Select Max(Audit_Id)
from Audit" made me wonder.)
Have you checked the contents of the audit log? If it was written
from UDFs in interbase triggers, make sure the UDFs did not write the
2byte size prefix that accompanies all varchar fields.
Are you using variants at all? eg. Reading the value from the audit
log into a variant and then assigning to the column AsVariant. Should
work, but variants are interesting things :-)
Is it possible for you to reproduce this in a sample application and
database and send it to me privately? (geoff@...)
Geoff Worboys
Telesis Computing
> Also from your reply doing a select * will insert all fields andIf the dataset CheckRequired property is true (the default), then IBO
> set the non specified fields to Null... so what happens if the
> table definition defines Not Null for some fields?
itself will detect the null fields and give you an error. If
CheckRequired is false, the null fields will get through to the server
and the error will come from there.
> I was assuming that the table defaults would spring intoIf you have entries in the dataset DefaultValues stringlist property,
> action... when I have defaults on a field,
these will be applied to inserted records, but defaults defined at the
server will not be used unless the field itself is NOT part of the
insert.
> no error is raised about trying to insert a null into a not nullWhich just proves that the data you are seeing in the monitor is
> field when posting or committing so I assumed this is what was
> happening.
really there (so it is not a monitor bug :-)
> What I do is read through an audit file. Each line in the file tellsThis leads to lots of questions :-)
> me to either insert a record or a update one particular field of the
> table in question.
How do you select the record for update? That is; Firstly where do
you get your key value from. Secondly I do not see the
select/retrieve of the row to be edited in the monitor output - you
can turn on the Row option of the monitor to see individual rows
returned from the server. This should demonstrate whether the rows
are being returned with these strange characters.
Perhaps you can see the curious logic here. If the problem is
happening on update, then the NOT NULL fields must have contained
something originally. So that data should be returned when the record
was selected for update. So either the row was updated by your
processing OR the row contained the strange data to begin with.
You say you are reading from file, is this an external table defined
to Interbase or is it truly just a file? (The "Select Max(Audit_Id)
from Audit" made me wonder.)
Have you checked the contents of the audit log? If it was written
from UDFs in interbase triggers, make sure the UDFs did not write the
2byte size prefix that accompanies all varchar fields.
Are you using variants at all? eg. Reading the value from the audit
log into a variant and then assigning to the column AsVariant. Should
work, but variants are interesting things :-)
Is it possible for you to reproduce this in a sample application and
database and send it to me privately? (geoff@...)
Geoff Worboys
Telesis Computing