Hi All,

Not sure if this an EDB problem or something more generic.

I have a form using TDBEdit fields showing data from an TEDBQuery, when
pressing a button called cancel, it gives the option to delete the record.

Now if I use code...

MyQuery->Delete();

It deletes the record as it closes the form. All good.

But if that record is the ONLY record in the query I get the error...

test.exe raised an exception class EConvertError with message "" is not
a valid date and time'

This only happens when it's the only record in the query, otherwise its
fine.

It sounds like after the record is deleted there are NO other records
for the cursor to jump to and so it falls over.

Any ideas?

Phil.

The live edit fields are expecting a record from which to pull data.
I'm guessing regular text fields (assuming you have some) are OK because
they translate the NULL values from the non-existent record to blanks.
But the date fields need some numeric value to convert the date and time
to something it can show--they don't handle the NULL value (which
results from no record being there) very well.

In my opinion, the standard date/time edit controls in Windows to which
Delphi's VCL wraps around are rather lame.  I much prefer the date/time
edits from the JVCL library (open source) which allows a NULL value for
the date/time edit control and even allows you to specify what you want
displayed in the control field instead of blank or 31-Dec-1899, which is
date zero.

So either prevent the DBEdit fields from showing anything at all
(probably have to actually disable or disconnect them) when there is no
record, or switch them to a control that can actually handle a NULL value.

BTW, this would happen for ANY database, not just EDB.  

--
David Cornelius
Cornelius Concepts

On 08/23/2012 10:57 PM, Phil wrote:
> Hi All,
>
> Not sure if this an EDB problem or something more generic.
>
> I have a form using TDBEdit fields showing data from an TEDBQuery, when
> pressing a button called cancel, it gives the option to delete the record.
>
> Now if I use code...
>
> MyQuery->Delete();
>
> It deletes the record as it closes the form. All good.
>
> But if that record is the ONLY record in the query I get the error...
>
> test.exe raised an exception class EConvertError with message "" is not
> a valid date and time'
>
> This only happens when it's the only record in the query, otherwise its
> fine.
>
> It sounds like after the record is deleted there are NO other records
> for the cursor to jump to and so it falls over.
>
> Any ideas?
>
> Phil.

On 24/08/2012 4:43 PM, David Cornelius wrote:
> The live edit fields are expecting a record from which to pull data. I'm
> guessing regular text fields (assuming you have some) are OK because
> they translate the NULL values from the non-existent record to blanks.
> But the date fields need some numeric value to convert the date and time
> to something it can show--they don't handle the NULL value (which
> results from no record being there) very well.
>
> In my opinion, the standard date/time edit controls in Windows to which
> Delphi's VCL wraps around are rather lame.  I much prefer the date/time
> edits from the JVCL library (open source) which allows a NULL value for
> the date/time edit control and even allows you to specify what you want
> displayed in the control field instead of blank or 31-Dec-1899, which is
> date zero.
>
> So either prevent the DBEdit fields from showing anything at all
> (probably have to actually disable or disconnect them) when there is no
> record, or switch them to a control that can actually handle a NULL value.
>
> BTW, this would happen for ANY database, not just EDB.  
>

Thanks David, yeah that was my first thought but the form only uses
basic TEDBEdit fields and the 2 x TIMESTAMP fields from the table are
not even shown on the form as Edit / Pickers what so ever.

This is why I'm puzzled... Even if I set the DataSource of the Query to
NULL prior to calling Delete() it still happens.

Hi David,

Thanks for your help... It wasn't the form... There was another
component on another form that had access to the same datasource (DOH).

So just setting the datasource to NULL for that component temporarily
works around it.

Thanks again for your input, enjoy your weekend.

Phil.

OK I lied, that wasn't it, still have the problem. DOH!

On 24/08/2012 5:13 PM, Phil wrote:
> OK I lied, that wasn't it, still have the problem. DOH!

It fails on the DB.pas line "Resync([]);" (see below)

I cant see any other controls using those fields, infact no other fields
in my program use DBEdits linked to that query.

Puzzling!


procedure TDataSet.Delete;
begin
  CheckActive;
  if State in [dsInsert, dsSetKey] then Cancel else
  begin
    if FRecordCount = 0 then DatabaseError(SDataSetEmpty, Self);
    DataEvent(deCheckBrowseMode, 0);
    DoBeforeDelete;
    DoBeforeScroll;
    CheckOperation(InternalDelete, FOnDeleteError);
    FreeFieldBuffers;
    SetState(dsBrowse);
    Resync([]);
    DoAfterDelete;
    DoAfterScroll;
  end;
end;

Phil


As a guess you have some events that are being triggered on change of data ie when the dataset is scrolled, after post, before post, CalcFields something. Its the same effect that I've encountered several times and I generally have two variables in my apps - FormClosing (per form) and AppClosing. These are created as False and set in the appropriate close event. Problem events then have a test:

If FormClosing or AppClosing then Exit;

Working out which are the problem events is generally a PITA

Roy Lambert [Team Elevate]

> Phil
>
>
> As a guess you have some events that are being triggered on change of data ie when the dataset is scrolled, after post, before post, CalcFields something. Its the same effect that I've encountered several times and I generally have two variables in my apps - FormClosing (per form) and AppClosing. These are created as False and set in the appropriate close event. Problem events then have a test:
>
> If FormClosing or AppClosing then Exit;
>
> Working out which are the problem events is generally a PITA
>
> Roy Lambert [Team Elevate]
>

Thanks Roy,

Its a strange one, I've listed all TDBDateTime pickers in my app and all
TDB fields that use the QuerySource for that query and there are none
besides standard TDBEdit fields accessing plain VarChar fields and yet
I'm still getting it.

I turned off the only other thing that uses the query and uses dates and
that was the DBTimeLineSource1 (part of the TMS DBPlanner).

I'll keep searching,

Cheers,

Phil.

Phil

>Its a strange one, I've listed all TDBDateTime pickers in my app and all
>TDB fields that use the QuerySource for that query and there are none
>besides standard TDBEdit fields accessing plain VarChar fields and yet
>I'm still getting it.

Tell me about it.

As an experiment what happens if you open the query with SQL guaranteed to produce no records. Do you still get the error?

Trying to trace stuff through TDataset is a bit of a nightmare but what happens if you trace into Resync. I think you stopped a bit early. Resync basically grabs and displays the "current" record. Your problem has to come from something trying to evaluate the DateTime. It won't be ElevateDB (otherwise it would fall over so much) but rather a component or a bit of code.

My worst case ever took me 2 full days to track down

Roy Lambert [Team Elevate]

> Tell me about it.
>
> As an experiment what happens if you open the query with SQL guaranteed to produce no records. Do you still get the error?
>
> Trying to trace stuff through TDataset is a bit of a nightmare but what happens if you trace into Resync. I think you stopped a bit early. Resync basically grabs and displays the "current" record. Your problem has to come from something trying to evaluate the DateTime. It won't be ElevateDB (otherwise it would fall over so much) but rather a component or a bit of code.
>
> My worst case ever took me 2 full days to track down
>
> Roy Lambert [Team Elevate]


Roy, what you said was very helpful indeed.

I just went through the form of about 40 components, removed their
datasource and listsources (for lookups) and then ran and it allows me
to delete...

So then I took to slowly putting certain ones back until I found the ONE
culprit which was the last one I tried of course.

It was a DBCheckBox of all things that has an OnClick Event... Well that
makes no logic, it's not being clicked by the user, but is still firing
off when the record is deleted. Go figure?

I'll have to set a flag in the OnClick event to test if I've pressed the
cancel button.

Am I missing something, why would an OnClick event fire from a
DBCheckBox when deleting a record.

Thanks again, at least I've nailed it down.

Much appreciate Roy and thanks also David.

Phil