Hi,

We have a client who has started receiving '11013' errors indicating 'Access
denied to table 483216'.  As I undesrtand these are temporary tables.  Under
client/server scenraio I presume the temp directory is specified in the
dbadmin tool.  This appears to be valid and files with today's date are
there.  I'm nit quite understanding how access could be denied under these
conditions.  Any advice?

Also there seems to be alot of old temop files in the temop directory.
Shouldn't they generally be deleted automatically?

Thanks

Alex

Oh yes, using DBISAM 3.30

Thanks

Alex


"Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
news:22FA748B-A530-47C4-9CB1-05B32056A8D0@news.elevatesoft.com...
> Hi,
>
> We have a client who has started receiving '11013' errors indicating
> 'Access denied to table 483216'.  As I undesrtand these are temporary
> tables.  Under client/server scenraio I presume the temp directory is
> specified in the dbadmin tool.  This appears to be valid and files with
> today's date are there.  I'm nit quite understanding how access could be
> denied under these conditions.  Any advice?
>
> Also there seems to be alot of old temop files in the temop directory.
> Shouldn't they generally be deleted automatically?
>
> Thanks
>
> Alex
>

Hi Alex,

Has the client recently changed server OS? The server login needs to have
read/write access to the configured temporary folder.

Temporary files are cleaned up automatically by the server. If not, it
indicates either an application problem (users encountering AVs), or the
server being turned off (or losing power) while the application is in use.

--
Best regards

Steve

"Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
news:22FA748B-A530-47C4-9CB1-05B32056A8D0@news.elevatesoft.com...
> Hi,
>
> We have a client who has started receiving '11013' errors indicating
> 'Access denied to table 483216'.  As I undesrtand these are temporary
> tables.  Under client/server scenraio I presume the temp directory is
> specified in the dbadmin tool.  This appears to be valid and files with
> today's date are there.  I'm nit quite understanding how access could be
> denied under these conditions.  Any advice?
>
> Also there seems to be alot of old temop files in the temop directory.
> Shouldn't they generally be deleted automatically?
>
> Thanks
>
> Alex
>

Hi Steve,

No its the same OS, nothing has changed there. Rights issue was the first
thing we checked.  We even changed the temp directory to see if that would
resolve the issue, to no avail.  We are now thinking there may be corruption
in files.  It's weird though that on our first check for errors using Verify
there were none, but running it again did produce errors.  It doesn't appear
that the Verify works properly???

As we speak we have just repaired all files to see whether that resolved the
issue, and it didnt.  Converting to DBISAM has been a nightmare for us.  In
between this issue, corrupt buffer indexes, immense slowness, records being
deleted without warning when repairing files, and more, not much sleep has
been had.  I am sure others will testify to DBISAM however at this early
stage we are finding potentially that DBISAM server is not as stable as we
would have expected for this medium-volume app.  I'm sure a few issues are
from our own code, but Paradox was remarkably stable for us, even with up to
10 users pumping alot of data through the system.  The frustration is
paramount.

Alex

"Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
news:F6F0E228-E54B-43C5-ACF2-15426EF6E6FE@news.elevatesoft.com...
> Hi Alex,
>
> Has the client recently changed server OS? The server login needs to have
> read/write access to the configured temporary folder.
>
> Temporary files are cleaned up automatically by the server. If not, it
> indicates either an application problem (users encountering AVs), or the
> server being turned off (or losing power) while the application is in use.
>
> --
> Best regards
>
> Steve
>
> "Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
> news:22FA748B-A530-47C4-9CB1-05B32056A8D0@news.elevatesoft.com...
>> Hi,
>>
>> We have a client who has started receiving '11013' errors indicating
>> 'Access denied to table 483216'.  As I undesrtand these are temporary
>> tables.  Under client/server scenraio I presume the temp directory is
>> specified in the dbadmin tool.  This appears to be valid and files with
>> today's date are there.  I'm nit quite understanding how access could be
>> denied under these conditions.  Any advice?
>>
>> Also there seems to be alot of old temop files in the temop directory.
>> Shouldn't they generally be deleted automatically?
>>
>> Thanks
>>
>> Alex
>>
>
>

Just tried accessing the application using non-client server and came up
with a similar access issue but this time from the user's temp directory
(local settings etc)

Just can't understand why this is happening when there have been no changes
to application, and been running relatively fine since new version was
installed 3 weeks ago.

Regards

Alex
"Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
news:219C0D4D-1238-4A8E-A06C-0211BDA237ED@news.elevatesoft.com...
> Hi Steve,
>
> No its the same OS, nothing has changed there. Rights issue was the first
> thing we checked.  We even changed the temp directory to see if that would
> resolve the issue, to no avail.  We are now thinking there may be
> corruption in files.  It's weird though that on our first check for errors
> using Verify there were none, but running it again did produce errors.  It
> doesn't appear that the Verify works properly???
>
> As we speak we have just repaired all files to see whether that resolved
> the issue, and it didnt.  Converting to DBISAM has been a nightmare for
> us.  In between this issue, corrupt buffer indexes, immense slowness,
> records being deleted without warning when repairing files, and more, not
> much sleep has been had.  I am sure others will testify to DBISAM however
> at this early stage we are finding potentially that DBISAM server is not
> as stable as we would have expected for this medium-volume app.  I'm sure
> a few issues are from our own code, but Paradox was remarkably stable for
> us, even with up to 10 users pumping alot of data through the system.  The
> frustration is paramount.
>
> Alex
>
> "Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
> news:F6F0E228-E54B-43C5-ACF2-15426EF6E6FE@news.elevatesoft.com...
>> Hi Alex,
>>
>> Has the client recently changed server OS? The server login needs to have
>> read/write access to the configured temporary folder.
>>
>> Temporary files are cleaned up automatically by the server. If not, it
>> indicates either an application problem (users encountering AVs), or the
>> server being turned off (or losing power) while the application is in
>> use.
>>
>> --
>> Best regards
>>
>> Steve
>>
>> "Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
>> news:22FA748B-A530-47C4-9CB1-05B32056A8D0@news.elevatesoft.com...
>>> Hi,
>>>
>>> We have a client who has started receiving '11013' errors indicating
>>> 'Access denied to table 483216'.  As I undesrtand these are temporary
>>> tables.  Under client/server scenraio I presume the temp directory is
>>> specified in the dbadmin tool.  This appears to be valid and files with
>>> today's date are there.  I'm nit quite understanding how access could be
>>> denied under these conditions.  Any advice?
>>>
>>> Also there seems to be alot of old temop files in the temop directory.
>>> Shouldn't they generally be deleted automatically?
>>>
>>> Thanks
>>>
>>> Alex
>>>
>>
>>
>
>

Hi Alex,

In my experience, DBISAM C/S is pretty well rock solid and performs very
well. I won't presume to tell you how to suck eggs, but here's a few think
you might want to consider:

You may well need to revisit some of your data presentation logic, as the
desktop query/display all records approach (which was probably being used in
your Paradox version) does not always translate well to C/S. Keep your
browsing record sets as lean as possible, returning full details only for
editing/reporting purposes. Indexing is also is very important, make sure
all filter/query criteria are appropriately indexed and be mindful of
case-sensitivity.

I have never experienced corruption, unexpected deletion of records or any
other unforseen behaviour when using DBISAM C/S.

--
Best regards

Steve

"Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
news:219C0D4D-1238-4A8E-A06C-0211BDA237ED@news.elevatesoft.com...
> Hi Steve,
>
> No its the same OS, nothing has changed there. Rights issue was the first
> thing we checked.  We even changed the temp directory to see if that would
> resolve the issue, to no avail.  We are now thinking there may be
> corruption in files.  It's weird though that on our first check for errors
> using Verify there were none, but running it again did produce errors.  It
> doesn't appear that the Verify works properly???
>
> As we speak we have just repaired all files to see whether that resolved
> the issue, and it didnt.  Converting to DBISAM has been a nightmare for
> us.  In between this issue, corrupt buffer indexes, immense slowness,
> records being deleted without warning when repairing files, and more, not
> much sleep has been had.  I am sure others will testify to DBISAM however
> at this early stage we are finding potentially that DBISAM server is not
> as stable as we would have expected for this medium-volume app.  I'm sure
> a few issues are from our own code, but Paradox was remarkably stable for
> us, even with up to 10 users pumping alot of data through the system.  The
> frustration is paramount.
>
> Alex
>
> "Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
> news:F6F0E228-E54B-43C5-ACF2-15426EF6E6FE@news.elevatesoft.com...
>> Hi Alex,
>>
>> Has the client recently changed server OS? The server login needs to have
>> read/write access to the configured temporary folder.
>>
>> Temporary files are cleaned up automatically by the server. If not, it
>> indicates either an application problem (users encountering AVs), or the
>> server being turned off (or losing power) while the application is in
>> use.
>>
>> --
>> Best regards
>>
>> Steve
>>
>> "Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
>> news:22FA748B-A530-47C4-9CB1-05B32056A8D0@news.elevatesoft.com...
>>> Hi,
>>>
>>> We have a client who has started receiving '11013' errors indicating
>>> 'Access denied to table 483216'.  As I undesrtand these are temporary
>>> tables.  Under client/server scenraio I presume the temp directory is
>>> specified in the dbadmin tool.  This appears to be valid and files with
>>> today's date are there.  I'm nit quite understanding how access could be
>>> denied under these conditions.  Any advice?
>>>
>>> Also there seems to be alot of old temop files in the temop directory.
>>> Shouldn't they generally be deleted automatically?
>>>
>>> Thanks
>>>
>>> Alex
>>>
>>
>>
>
>

Hi Alex,

Have there been any updates to, or changes in Firewall or Virus software or
settings? Sounds like an environmental issue to me.
--
Best regards

Steve

"Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
news:17519A77-DBE2-4B85-8B87-F06A75B45759@news.elevatesoft.com...
> Just tried accessing the application using non-client server and came up
> with a similar access issue but this time from the user's temp directory
> (local settings etc)
>
> Just can't understand why this is happening when there have been no
> changes to application, and been running relatively fine since new version
> was installed 3 weeks ago.
>
> Regards

Al,

> Just can't understand why this is happening when there have been no changes
> to application, and been running relatively fine since new version was
> installed 3 weeks ago.

It is happening because there has been a change to the environment. At
first glance this smells like a virus checker (Norton?) update being
deployed and farkling with the temporary query result set files. The
user will probably claim that "nothing has changed" because he/she
doesn't regard the automated update of a virus scanner as changing anything.

Eryk

Thanks guys,

Just a bit of frustration as I said.  We are fully committed to DBISAM,
there's no real turning back anyway.  As it happnes, you and Eric were
correct.  The issue was a result of a stupid antivirus update.  Uninstalled
it completely and everything working fine again.  It's the unfortunate thing
in software business that when things don't work, the software is
immediately blamed.  Was fully aware of the virus-type issues but just
didn't click that their virus checker might have been updated automatically,
and would suddenly cause this sort of issue.  Have suggested to their
network support consultant that maybe they have virus checkers at the client
PC level rather than on the application server.

Thanks again for all your help.

Regards

Alex




"Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
news:E1D4E4F0-A897-4866-98BC-F39EDBF3C24B@news.elevatesoft.com...
> Hi Alex,
>
> In my experience, DBISAM C/S is pretty well rock solid and performs very
> well. I won't presume to tell you how to suck eggs, but here's a few think
> you might want to consider:
>
> You may well need to revisit some of your data presentation logic, as the
> desktop query/display all records approach (which was probably being used
> in your Paradox version) does not always translate well to C/S. Keep your
> browsing record sets as lean as possible, returning full details only for
> editing/reporting purposes. Indexing is also is very important, make sure
> all filter/query criteria are appropriately indexed and be mindful of
> case-sensitivity.
>
> I have never experienced corruption, unexpected deletion of records or any
> other unforseen behaviour when using DBISAM C/S.
>
> --
> Best regards
>
> Steve
>
> "Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
> news:219C0D4D-1238-4A8E-A06C-0211BDA237ED@news.elevatesoft.com...
>> Hi Steve,
>>
>> No its the same OS, nothing has changed there. Rights issue was the first
>> thing we checked.  We even changed the temp directory to see if that
>> would resolve the issue, to no avail.  We are now thinking there may be
>> corruption in files.  It's weird though that on our first check for
>> errors using Verify there were none, but running it again did produce
>> errors.  It doesn't appear that the Verify works properly???
>>
>> As we speak we have just repaired all files to see whether that resolved
>> the issue, and it didnt.  Converting to DBISAM has been a nightmare for
>> us.  In between this issue, corrupt buffer indexes, immense slowness,
>> records being deleted without warning when repairing files, and more, not
>> much sleep has been had.  I am sure others will testify to DBISAM however
>> at this early stage we are finding potentially that DBISAM server is not
>> as stable as we would have expected for this medium-volume app.  I'm sure
>> a few issues are from our own code, but Paradox was remarkably stable for
>> us, even with up to 10 users pumping alot of data through the system.
>> The frustration is paramount.
>>
>> Alex
>>
>> "Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
>> news:F6F0E228-E54B-43C5-ACF2-15426EF6E6FE@news.elevatesoft.com...
>>> Hi Alex,
>>>
>>> Has the client recently changed server OS? The server login needs to
>>> have read/write access to the configured temporary folder.
>>>
>>> Temporary files are cleaned up automatically by the server. If not, it
>>> indicates either an application problem (users encountering AVs), or the
>>> server being turned off (or losing power) while the application is in
>>> use.
>>>
>>> --
>>> Best regards
>>>
>>> Steve
>>>
>>> "Al VAs" <deleteprefix_alex@favour.com.au> wrote in message
>>> news:22FA748B-A530-47C4-9CB1-05B32056A8D0@news.elevatesoft.com...
>>>> Hi,
>>>>
>>>> We have a client who has started receiving '11013' errors indicating
>>>> 'Access denied to table 483216'.  As I undesrtand these are temporary
>>>> tables.  Under client/server scenraio I presume the temp directory is
>>>> specified in the dbadmin tool.  This appears to be valid and files with
>>>> today's date are there.  I'm nit quite understanding how access could
>>>> be denied under these conditions.  Any advice?
>>>>
>>>> Also there seems to be alot of old temop files in the temop directory.
>>>> Shouldn't they generally be deleted automatically?
>>>>
>>>> Thanks
>>>>
>>>> Alex
>>>>
>>>
>>>
>>
>>
>
>

Al VAs wrote:

> It's the unfortunate thing in software business that when things
> don't work, the software is immediately blamed.  

A new client once blamed my software for cauisng an electrical short
which fried their server.  They said the only thing that had changed
was the installation of my software.