 | | From: | Erich Zippel | | Subject: | potential Timestamp/SQL- Bug | | Date: | Fri, 21 Jan 2005 19:17:28 +0100 |
|
|
 | I had a lot of memery access violation problems with my forms when changing
to 2.5.
I tried to isolate the problem. The most I got is in dbase.binaries for
verifying by somebody else (there are 6 forms and one set of data).
What I could boil down the problem to is the following:
The problem exists in 2.21 and 2.5, the effects are different though.
There is a Autoinc field with an index and a Timestamp with NULL-entries in
the table.
When one displays the timestamp in the form 2.21 returns weird data values
instead and 2.5
crashes when certain conditions are given in the sql-statement.
The statements involve esp. 'Like' and 'In'. The behaviour somehow seems to
depend on the existence of an Order clause also.
|
|
| | From: | Bruce Beacham | | Subject: | Re: potential Timestamp/SQL- Bug | | Date: | Sat, 22 Jan 2005 09:37:46 +0000 |
|
|
| > The statements involve esp. 'Like' and 'In'. The behaviour somehow seems to
> depend on the existence of an Order clause also.
Is there a complex index (ie using dBL functions) on the timestamp field?
In particular:
dttot(datetime)
Bruce Beacham
|
|
| | From: | Erich Zippel | | Subject: | Re: potential Timestamp/SQL- Bug | | Date: | Sat, 22 Jan 2005 14:32:31 +0100 |
|
|
| No index at all on the involved timestamp.
Somehow indexes on the Autoinc seem to make some difference though.
Erich Zippel
"Bruce Beacham" schrieb im Newsbeitrag
news:%238r2DZGAFHA.1456@news-server...
>> The statements involve esp. 'Like' and 'In'. The behaviour somehow seems
>> to depend on the existence of an Order clause also.
>
> Is there a complex index (ie using dBL functions) on the timestamp field?
>
> In particular:
> dttot(datetime)
>
>
> Bruce Beacham
|
|
| | From: | Ivar B. Jessen | | Subject: | Re: potential Timestamp/SQL- Bug | | Date: | Sat, 22 Jan 2005 14:43:54 +0100 |
|
|
| Sat, 22 Jan 2005 14:32:31 +0100 chr(10) dbase.bug-reports chr(10)Re:
potential Timestamp/SQL- Bug chr(10) "Erich Zippel"
chr(10)
>No index at all on the involved timestamp.
>Somehow indexes on the Autoinc seem to make some difference though.
>
>Erich Zippel
Erich,
The table bug.dbf does _not_ have a field of type Autoincrement. The
field IDO is of type Long.
Maybe it would help others to understand the problem if you told for
each form what result you see and what you expected to see.
Ivar B. Jessen
|
|
| | From: | Erich Zippel | | Subject: | Re: potential Timestamp/SQL- Bug | | Date: | Sat, 22 Jan 2005 16:13:29 +0100 |
|
|
| Sorry,
What happens for me with v 2.5 is:
Memory Access Violation with full closedownon pressing Button for Nr 2,3,5
Ok in Nr 1,6
Ok with an initial strange 'B.C.' value removed by pressing button on Nr. 4
A respective value of '4693-03-11 BC:00:00:00' in v2.21 instead of the
crashes.
Sorry about the Autoinc. That apperently was from an earlier step in the
boil-down
during holidays.
Erich Zippel.
"Ivar B. Jessen" schrieb im Newsbeitrag
news:n4m4v05uvvv9p70p01b908h2rc77m7ek04@4ax.com...
> Sat, 22 Jan 2005 14:32:31 +0100 chr(10) dbase.bug-reports chr(10)Re:
> potential Timestamp/SQL- Bug chr(10) "Erich Zippel"
> chr(10)
>
>>No index at all on the involved timestamp.
>>Somehow indexes on the Autoinc seem to make some difference though.
>>
>>Erich Zippel
>
> Erich,
>
> The table bug.dbf does _not_ have a field of type Autoincrement. The
> field IDO is of type Long.
>
> Maybe it would help others to understand the problem if you told for
> each form what result you see and what you expected to see.
>
>
> Ivar B. Jessen
|
|
| | From: | Ivar B. Jessen | | Subject: | Re: potential Timestamp/SQL- Bug | | Date: | Sat, 22 Jan 2005 18:35:00 +0100 |
|
|
| Sat, 22 Jan 2005 16:13:29 +0100 chr(10) dbase.bug-reports chr(10)Re:
potential Timestamp/SQL- Bug chr(10) "Erich Zippel"
chr(10)
>Sorry,
>What happens for me with v 2.5 is:
>Memory Access Violation with full closedownon pressing Button for Nr 2,3,5
>Ok in Nr 1,6
>Ok with an initial strange 'B.C.' value removed by pressing button on Nr. 4
>
>A respective value of '4693-03-11 BC:00:00:00' in v2.21 instead of the
>crashes.
In W2000 I do not see memory access violations, only some BC dates.
As you do not have an entryfield in Zebug06.wfm for field Invalidated
how you do you know that you don't have strange dates :-)
Have you tried if you get the same problems when you remove the
spinboxes and the default values in the table?
>Sorry about the Autoinc. That apperently was from an earlier step in the
>boil-down
>during holidays.
Don't make any serious work on holidays.
Ivar B. Jessen
|
|
| | From: | Erich Zippel | | Subject: | Re: potential Timestamp/SQL- Bug | | Date: | Sun, 23 Jan 2005 16:45:36 +0100 |
|
|
| Hi,
thanks for looking.
When verifying your idea I found a more distinct boiled down version of the
problem. And it gets
wyrder still.
Still dependent on the presence of Null-Timestamp the crahs seems to be
triggered by something
else.
Following form runs ok on requery-button. But if uncommenting the other
field it crashes on requery.
Changing the order of the fields then runs ok again.
Erich Zippel
** END HEADER -- do not remove this line
//
// Generated on 2004-12-28
//
parameter bModal
local f
f = new zebug05Form()
if (bModal)
f.mdi = false // ensure not MDI
f.readModal()
else
f.open()
endif
class zebug05Form of FORM
with (this)
colorNormal = "dimgray"
height = 7.9545
left = 18.8571
top = 8.2727
width = 42.4286
text = ""
endwith
this.LISTE1 = new QUERY()
this.LISTE1.parent = this
with (this.LISTE1)
left = 5.0
top = -0.0455
sql = "select * from bug.dbf WHERE Text LIKE '%N%' ORDER BY IDO"
active = true
endwith
this.PUSHBUTTON1 = new PUSHBUTTON(this)
with (this.PUSHBUTTON1)
onClick = class::PUSHBUTTON1_ONCLICK
height = 1.0
left = 4.0
top = 5.5
width = 34.0
text = "Requery"
endwith
/*
// uncommented crashes dB250 with MAV
this.ENTRYFIELDID1 = new ENTRYFIELD(this)
with (this.ENTRYFIELDID1)
dataLink = form.liste1.rowset.fields["text"]
height = 1.0
left = 15.0
top = 2.0
width = 23.0
colorNormal = "cornsilk/steelblue"
endwith
*/
this.Field1 = new Entryfield(this)
with (this.Field1)
dataLink = form.liste1.rowset.fields["invalidated"]
height = 1.0
left = 15.0
top = 4.0
width = 23.0
colorNormal = "cornsilk/steelblue"
endwith
this.rowset = this.liste1.rowset
function PUSHBUTTON1_onClick
form.rowset.parent.sql = "select * from bug.dbf WHERE Text LIKE '%N%'
ORDER BY IDO"
form.rowset.parent.requery()
return
endclass
"Ivar B. Jessen" schrieb im Newsbeitrag
news:mk35v0ddt7r64es2ueknt7pdcovrkt3r01@4ax.com...
> Sat, 22 Jan 2005 16:13:29 +0100 chr(10) dbase.bug-reports chr(10)Re:
> potential Timestamp/SQL- Bug chr(10) "Erich Zippel"
> chr(10)
>
>>Sorry,
>>What happens for me with v 2.5 is:
>>Memory Access Violation with full closedownon pressing Button for Nr 2,3,5
>>Ok in Nr 1,6
>>Ok with an initial strange 'B.C.' value removed by pressing button on Nr.
>>4
>>
>>A respective value of '4693-03-11 BC:00:00:00' in v2.21 instead of the
>>crashes.
>
> In W2000 I do not see memory access violations, only some BC dates.
>
> As you do not have an entryfield in Zebug06.wfm for field Invalidated
> how you do you know that you don't have strange dates :-)
>
> Have you tried if you get the same problems when you remove the
> spinboxes and the default values in the table?
>
>>Sorry about the Autoinc. That apperently was from an earlier step in the
>>boil-down
>>during holidays.
>
> Don't make any serious work on holidays.
>
>
> Ivar B. Jessen
|
|
