Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread Broken Table
Fri, Oct 11 2013 1:49 AMPermanent Link

Danie van Eeden

Hi,

I have a broken table giving me the following error as your scroll through it with dbsys (some records only).

---------------------------
Error
---------------------------
'-6406.0' is not a valid timestamp
---------------------------
OK   
---------------------------

Normal table repairs do not seem to find any faults and I cannot see any data anomalies by looking at the data itself. I fear my knowledge of the DBISAM file structure is too limited to see any differences with HEX as well.

Any advice greatly appreciated.

Kind Regards
Danie
Fri, Oct 11 2013 3:13 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Danie


It is a valid timestamp - I make it

---------------------------
Project1
---------------------------
16/06/1882
---------------------------
OK  
---------------------------

using showmessage(datetimetostr(-6406.0));

so that suggests there is something else wrong and my guess would be you have a control character embedded in there somewhere. Most likely being a #13.

What happens if you export the table to csv format. Does that work, and if so does it give you the right information? If it does then you can simply export and import.

Another option to try is to use Delphi and run through the table in navigational mode. Just read the duff field into a local datetime variable. Use a try..except block to catch any exception and clear the field when one is. You can also build a list of IDs for the take so you can see what records have been affected.

Final suggestion - open a support ticket and ask Tim to have a look at the table.

Without knowing what your app is the date 16/06/1882 does look as though something is wrong somewhere in your code.

Roy Lambert [Team Elevate]
Fri, Oct 11 2013 3:39 AMPermanent Link

Danie van Eeden

Hi Roy, thanks for the reply. Yes indeed I agree that anything < 0 is invalid.

Looking at the data for those records in DBSYS view, all date fields seem valid.
I will try the CSV export and see what I get.
In hindsight, the table design will not allow for a simple export and re-import - we has a autonc that is, unfortunately, being used for linking to a child table.(yeah I know, this wasn't all that smart).

If I export and import, the autonumbers are recreated and I would have to try and relink the data (I have done this before, but it was quite a timely exercise).

I like the second option with the try except and clear. Ill try that.

failing the above I will log the ticket.

Thanks again for the response.
Image