Under 2.03b5 (U) my code can happily DROP temporary tables.

After installing b6 I now get a #900 error.  Re-installing b5
restores the DROP-ability with no change to the source.

Has something changed that I missed in the release notes?  
I did try toggling the new engine propery ExclusiveFileAccess but
that made no difference.  

Full error text:

ElevateDB Error #900 An error occurred with the statement at line 17
and column 19 (Access violation at address 006703D4 in module
'DiveRecorder.exe'. Read of address 00000044).

Malcolm

--

Hi Tim

More info in the hope you stumble on this topic sometime.

1) In the B6 Manager using the same user and data, my scripts will
happily drop temporary tables.

2) In my app under B6 *every* call to DROP a temp table fails - in
various units.

3) In my app re-built under B5 *every* DROP succeeds.

So it seems to me that there is no bug in your code and, at least
under B5, none in mine.  This is why I ask if there has been some
change in B6 that you have covered in the B6 Manager and I need to
know about to fix my app?

Malcolm

--

Malcolm,

<< Under 2.03b5 (U) my code can happily DROP temporary tables.

After installing b6 I now get a #900 error.  Re-installing b5 restores the
DROP-ability with no change to the source. >>

I'm not able to reproduce this here.  Can you possibly email me something
that reproduces this ?

<< I did try toggling the new engine propery ExclusiveFileAccess but that
made no difference.  >>

Ignore that property for now - it has to do with preventing other processes
from opening the source table files, ala a single-user application that
doesn't want to allow concurrent access from other processes while the
application is running.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>
> I'm not able to reproduce this here.  Can you possibly email me
> something that reproduces this ?
>

Aaargh!  
Would the Session.KeepTablesOpen have any bearing?  
Turning that off seems to have fixed the problem subject to further
testing, phew.

--

Malcolm,

<< Aaargh!   Would the Session.KeepTablesOpen have any bearing?  Turning
that off seems to have fixed the problem subject to further testing, phew.
>>

It's possible, but I use KeepTablesOpen=True by default in the EDB Manager
when I test things, and it works fine with this script:

SCRIPT
BEGIN

BEGIN
  EXECUTE IMMEDIATE 'DROP TABLE "customer3"';
EXCEPTION
END;

EXECUTE IMMEDIATE 'CREATE TEMPORARY TABLE "customer3"
(
"CustNo" FLOAT,
"Company" VARCHAR(30) COLLATE "ANSI",
CONSTRAINT "PrimaryKey" PRIMARY KEY ("CustNo")
)';

EXECUTE IMMEDIATE 'DROP TABLE "customer3"';

END

Does the same script work for you in the EDB Manager with KeepTablesOpen set
to True (Edit Session/Database/Table Options) ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>
> Does the same script work for you in the EDB Manager with
> KeepTablesOpen set to True (Edit Session/Database/Table Options) ?

Tim

Yes it does .. if I change 'ANSI' to 'UNI'.  

I have no explanation, but having passed that test with
KeepTablesOpen=True in the Manager, I rebuilt two of my apps with
KeepTablesOpen=True and .. yes, you guessed it, they both AV'ed at
the Drop.
 
Then I set KeepTablesOpen=False in both, rebuilt and .. now they drop
without a murmur.  Go figure!  

At least I have a work around, but it is curious.

Malcolm
--

Malcolm,

<< I have no explanation, but having passed that test with
KeepTablesOpen=True in the Manager, I rebuilt two of my apps with
KeepTablesOpen=True and .. yes, you guessed it, they both AV'ed at the Drop.
>>

Is there any way that you can get that code out into a sample project that
you can send me ?  Or can you set it up to use the EDB Server ?  The second
way is usually easiest, because I can then just debug the server while your
application runs normally, and I only need the application .exe.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Is there any way that you can get that code out into a sample
> project that you can send me ?  Or can you set it up to use the EDB
> Server ?  The second way is usually easiest, because I can then
> just debug the server while your application runs normally, and I
> only need the application .exe.

OK, Tim, I will read up on the server.  I'm told it is dead easy to
switch!

But it may take a few days to get round to it now.

Malcolm

--

Tim Young [Elevate Software] wrote:

> Is there any way that you can get that code out into a sample
> project that you can send me ?  Or can you set it up to use the EDB
> Server ?  The second way is usually easiest, because I can then
> just debug the server while your application runs normally, and I
> only need the application .exe.

OK, Tim, I will read up on the server.  I'm told it is dead easy to
switch!

But it may take a few days to get round to it now.

Malcolm

--

Malcolm,

<< OK, Tim, I will read up on the server.  I'm told it is dead easy to
switch! >>

Yep, just switch the TEDBSession.SessionType property to stRemote, re-build,
and then make sure that the EDB Server is running on the local machine and
is configured to use the same configuration path that your application was
using locally (if you want to test the application to make sure that it is
working okay still .  Here are instructions on configuring the EDB
Server:

http://www.elevatesoft.com/manual?action=mantopic&id=edb2sql&category=0&topic=3

under "Starting the ElevateDB Server as a Normal Application"

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com