PDA

View Full Version : Request_Read access violation



Focus
29-Jan-2020, 04:47 AM
I'm trying to debug an access violation that is appearing in V20 that does not happen in 19.1

After many hours I have got as far as I can but I am now stuck as I can't debug it any further

The line of code that is being executed is



Send Request_Read LE (Main_File(Self)) 2


In 19.1 this is working fine and either finding or not finding the record it should

In 20.0 if it does not find a record then the code continues fine, however if it does find a record then we get an Access Violation

In terms of debugging the closest I can get is the End_Procedure of Data_Set_PreFind. After pressing F11 here it then crashes

Some things that I think are are probably relevant about this table are

It contains two Text fields. These are of type Text on the SQL side as that is what the CK has created in the past when a field DF_FIELD_TYPE has been set to DF_TEXT

The int file contains FIELD_LENGTH 65000 for these two fields

Is anyone out there testing an application in 20.0 that has Text fields this large in their tables ?

Focus
29-Jan-2020, 06:39 AM
This maybe a red herring but a bit more info

If I drop and rebuild the table with the data in it but the text fields "converted" to nvarchar(max) then we don't get an Access Violation

Doing a Request_Read on another table with a Text field that is much smaller (512 bytes rather than 65000) does not appear to cause an Access Violation but this is just a test of a single find

starzen
29-Jan-2020, 06:42 AM
hmm 65000, maybe argument size which defaults to 64k

Focus
29-Jan-2020, 07:13 AM
Could be, same code works in 19.1 though, so if it is, it 'must' be on the CK side

Focus
29-Jan-2020, 07:34 AM
Having an unscientific poke about I would say that the problem occurs on Text columns with a length of around 1024 or more (912 seems to be OK) but just take this as a guide rather than an absolute I know this.

I did try a simple copy of the CK that can with 20.0 into 19.1 environment but I got an error (not unexpected!) about the DFR file

Focus
30-Jan-2020, 02:36 AM
Hmmm 64k is obviously larger than 65000 :D

Harm Wibier
30-Jan-2020, 03:19 AM
Hmmm 64k is obviously larger than 65000 :D

Please note that the CK's are still undergoing a big overhaul. Please let us know if this problem still exists in the next build.

starzen
30-Jan-2020, 04:44 AM
it is but i wouldnt be surprised if that is the issue. there may be additional use of the string buffer that limits it to less than that

have you actually tried if it fixes it?

Focus
30-Jan-2020, 04:52 AM
It currently breaks on fields of around 1000 chars and above and I will test it again when they release TP3 with an updated CK

Peter Bragg
30-Jan-2020, 09:51 AM
I've also just hit an access violation on a request_read.

Interestingly in my case, the table contains no TEXT fields (using the term in the generic sense to also include varchar(max) and nvarchar(max)).
Interesting too that if I change the Request_Read to a simple 'Find GT' it no longer crashes.

So, the following crashes:



Send Clear of o<Table>_dd
Send Request_Read of o<Table>_dd FIRST_RECORD <Table>.File_Number 1


The following does not:



Clear <Table>
Find GT <Table> by Index.1




Database Explorer also crashes if I try and use it to show the contents of the table (but then this probably also uses Request_Reads?)

Same table in DF19.1 causes no problems.


Yet to find what's odd about the table. There are only 38 columns and they are a mixture of numeric, int and nchar, with the largest of the nchar fields being only length 255. The database certainly contains much larger and much more complicated tables.

I appreciate this isn't much help with regards to identifying the root cause, but just thought to report it.

Stephen W. Meeley
30-Jan-2020, 12:59 PM
Peter,

Can you send me the table?

Peter Bragg
31-Jan-2020, 04:20 AM
Will do. Will email it to you directly.

Stephen W. Meeley
31-Jan-2020, 10:29 AM
Peter,

I go the workspace and can reproduce the error (runs fine in 19.1). As harm mentioned earlier in the thread, the drivers are going through changes and the main reason I wanted to get this from you is so that, when the time comes (soon), I can test the updated driver with this and make sure it's addressed. Thanks!