Paul,

<< Although another problem has now presented itself, we have now had 3
sites saying that after awhile of use the DBSRVR will stop and deny any more
new connections. When this happens the message "Cannot open or create log
file C:\Path\to\logfile\DBSRVR.log for
database server." which is then shortly followed by an Access Violation in
DBSRVR. >>

Have you verified that there aren't any resource issues involved here also ?
The only reason the server wouldn't be able to create or open the log files
are:

1) User rights
2) System resources are too low (either memory or disk space).

<< I can send you these 2 log files if that helps? >>

It never hurts - please send them to timyoung@elevatesoft.com

--
Tim Young
Elevate Software
www.elevatesoft.com

Paul Candido wrote:
> Hi Tim,
>
> You were right a bit of eyeball over the code turned up that one of
> the queries I was using in my loop didn't have a close before free
> which was causing the memory to build.

Freeing a query should also close it. Or am I wrong here?

Ralf

Hi Tim,

<< Have you verified that there aren't any resource issues involved here also ?
The only reason the server wouldn't be able to create or open the log files
are:

1) User rights
2) System resources are too low (either memory or disk space). >>

I don't think it's User rights, as it has always been working with all these sites before
the service upgrade.
Disk space on one of the drives was 135gb free, and when it crashed at one of the other
schools the DBSRVR was using ~150mb of memory out of 2gb of physical memory and 3gb of
virtual memory.

We have had more reports from other sites today that the service isn't accepting any new
connections until they restart the service. Once the server decides it doesn't want to
accept any more sessions, it seems to me that people in the system can still use it (this
is unconfirmed).

I will try today restoring the older service we were using previous to

<< It never hurts - please send them to timyoung@elevatesoft.com >>

Sent.

Hi Ralf,

<< Freeing a query should also close it. Or am I wrong here? >>

I don't know if it should or not but this was the case with me, before i put the close in
the code the memory would just build with every loop, now it just stays steady.

Thanks,

- Paul

Just got some feed back from some of our sites, it seems as if the dbsrvr is having
troubles freeing memory associated with a session.

When a session is removed shouldn't it free all memory allocated to that session?
or maybe this error stopping it from doing that? -> [ERROR] Internal error removing
session [Access violation at address 7C8396D0 in module
'ntdll.dll'. Read of address 502D3AE5] [Client Version: 0.00 User Name: HD Address:
10.12.25.239 Encrypted: No Thread: 5036 Session: 44701704]

Ralf,

<< Freeing a query should also close it. Or am I wrong here? >>

You are right - I missed that.  A Free instead of a Close/Free makes no
difference at all.

--
Tim Young
Elevate Software
www.elevatesoft.com

Paul,

<< We have had more reports from other sites today that the service isn't
accepting any new connections until they restart the service. Once the
server decides it doesn't want to accept any more sessions, it seems to me
that people in the system can still use it (this is unconfirmed).

I will try today restoring the older service we were using previous to  >>

I doubt if that will make any difference - 4.22 and 4.24 are pretty much the
same thing except for 4.24 has bug fixes that 4.22 doesn't.  You can give it
a shot, I just wouldn't hold my breath.

As for the issue - I looked at the server logs that you sent, and the logs
are showing an external exception and then exceptions in ntdll.dll.  There
is no originating exception in the database server in terms of an AV, etc.
Now, it is certainly possible that an external exception could happen due to
an error in DBISAM, but it is extremely rare to not see an actual AV in
DBISAM first.  This indicates something pretty severe.

Are you using multiple threads in your client application(s) that are
accessing the DBISAM database server ?

Also, the first log that you sent shows only one client connecting and
disconnecting a few times, both as a normal user and an admin, before the
external exception occurs during the logout.  The whole series of
connects/disconnects only spans about 2 minutes.  What is your application
doing in terms of administrative access when connecting as the administrator
?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Ok, I've been doing some testing. All I need to do is login to our program and then just
exit. And we get the error when removing the session in DBSRVR.

<< I doubt if that will make any difference - 4.22 and 4.24 are pretty much the
same thing except for 4.24 has bug fixes that 4.22 doesn't.  You can give it
a shot, I just wouldn't hold my breath. >>

I downgraded my components on our program to 4.22 b5 and ran the 4.24 b1 dbsrvr, Login,
exited. I no longer receive the error when removing the session.

<< Are you using multiple threads in your client application(s) that are
accessing the DBISAM database server ? >>

Nope

<< Also, the first log that you sent shows only one client connecting and
disconnecting a few times, both as a normal user and an admin, before the
external exception occurs during the logout.  The whole series of
connects/disconnects only spans about 2 minutes.  What is your application
doing in terms of administrative access when connecting as the administrator
? >>

I don't know why this log had so many Logout's i cannot replicate this, all our program
does is Login as a generic user to gather the username. As soon as the user has a
successful login, the session disconnects and then connects as their DB Username. The
admin logins you see in that log is the Tech at the site logging into svradmin to check
the log/statistics.

I have no idea what we are doing different to everyone else using this version, but
something has changed between 4.22 b5 and 4.24 b1 in regards to clearing the sessions.

Is there any problem with running 4.22b5 components on a 4.24b1 dbsrvr?

Thanks,

- Paul

Paul,

<< Ok, I've been doing some testing. All I need to do is login to our
program and then just exit. And we get the error when removing the session
in DBSRVR. >>

Can you send me something that replicates this ?  I would really appreciate
it.  Or, at the very least, give me a run-down of the operations that are
occurring after the login.

<< I have no idea what we are doing different to everyone else using this
version, but something has changed between 4.22 b5 and 4.24 b1 in regards to
clearing the sessions. >>

Not that I'm aware of.  The only fixes are those listed here:

http://www.elevatesoft.com/scripts/incident.dll?action=list

However, that doesn't mean the something couldn't have been inadvertently
broken.  We do extensive regression testing of every release, but if it
wasn't an issue before then it may not have been caught.

<< Is there any problem with running 4.22b5 components on a 4.24b1 dbsrvr?
>>

Wait, so you're saying that the problem is related to using the 4.24B1
*client-side* components, and not the database server ?  IOW, if you keep
the database server at 4.24B1 and change the client components to 4.22B5,
the problem goes away ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< Can you send me something that replicates this ?  I would really appreciate
it.  Or, at the very least, give me a run-down of the operations that are
occurring after the login. >>

I'll work on trying to replicate this for you with some sample code tommorow.

<< Wait, so you're saying that the problem is related to using the 4.24B1
*client-side* components, and not the database server ?  IOW, if you keep
the database server at 4.24B1 and change the client components to 4.22B5,
the problem goes away ? >>

Correct, I found this a bit odd myself. No changes to code, just downgraded component and
the error went away.

I hope this helps you with locating the problem, be it my end or yours.

Thanks for your help again,

- Paul

Paul,

<< I'll work on trying to replicate this for you with some sample code
tommorow. >>

Thank you.

<< Correct, I found this a bit odd myself. No changes to code, just
downgraded component and the error went away.

I hope this helps you with locating the problem, be it my end or yours. >>

I'll try things out and see what I can find.

--
Tim Young
Elevate Software
www.elevatesoft.com