Hi All,

I have a timekeeping system that is connected thru a mapped drive to a
firebird DB.
Everything works fine when a lot of people are coming IN & OUT.
When the workstation is idle IDLE for about 1 hour, my IF NOT
tc.qlocate(empID) would fail for all subsequent users and the user would
need to exit my application and go back in (not logoff the PC but only exit
pdox) and everything works fine again.

All power schemes for the PC and NICs are set to never. We even added a
registry entry in the server to allow unlimited autodisconnect timeout but
this has not solved te problem. Before a tc.qlocate(empID) is performed, we
have IF NOT tc.Open("ATA:EMPFILE") ... and this does not raise an error.
I have a timer running on the form that displays the date and time. We have
tried to duplicate the problem in another small server and the problem does
not happen.

Any ideas?

TIA.

Gene

Hi Gene,

I'm not sure why it fails, but I can tell you that using TCursors and
any other Paradox specific construct against a CS database will only
lead to problems. It is not a question of if, but when. In the time it
takes you to figure this out, you can probably replace the TCursor with
a Firebird stored procedure using SQL which will work reliably every
time. Probably not what you wanted to hear, but I believe it is by far
the best way to go.

Regards,
RoyF



Gene De Guzman wrote:

Hi Gene,

I'm not sure why it fails, but I can tell you that using TCursors and
any other Paradox specific construct against a CS database will only
lead to problems. It is not a question of if, but when. In the time it
takes you to figure this out, you can probably replace the TCursor with
a Firebird stored procedure using SQL which will work reliably every
time. Probably not what you wanted to hear, but I believe it is by far
the best way to go.

Regards,
RoyF



Gene De Guzman wrote:

Hi Gene,

I'm not sure why it fails, but I can tell you that using TCursors and
any other Paradox specific construct against a CS database will only
lead to problems. It is not a question of if, but when. In the time it
takes you to figure this out, you can probably replace the TCursor with
a Firebird stored procedure using SQL which will work reliably every
time. Probably not what you wanted to hear, but I believe it is by far
the best way to go.

Regards,
RoyF



Gene De Guzman wrote:

Hi Gene,

I'm not sure why it fails, but I can tell you that using TCursors and
any other Paradox specific construct against a CS database will only
lead to problems. It is not a question of if, but when. In the time it
takes you to figure this out, you can probably replace the TCursor with
a Firebird stored procedure using SQL which will work reliably every
time. Probably not what you wanted to hear, but I believe it is by far
the best way to go.

Regards,
RoyF



Gene De Guzman wrote:

Hi Gene,

I'm not sure why it fails, but I can tell you that using TCursors and
any other Paradox specific construct against a CS database will only
lead to problems. It is not a question of if, but when. In the time it
takes you to figure this out, you can probably replace the TCursor with
a Firebird stored procedure using SQL which will work reliably every
time. Probably not what you wanted to hear, but I believe it is by far
the best way to go.

Regards,
RoyF



Gene De Guzman wrote:

Hi Gene,

I'm not sure why it fails, but I can tell you that using TCursors and
any other Paradox specific construct against a CS database will only
lead to problems. It is not a question of if, but when. In the time it
takes you to figure this out, you can probably replace the TCursor with
a Firebird stored procedure using SQL which will work reliably every
time. Probably not what you wanted to hear, but I believe it is by far
the best way to go.

Regards,
RoyF



Gene De Guzman wrote:

Hi Gene,

I'm not sure why it fails, but I can tell you that using TCursors and
any other Paradox specific construct against a CS database will only
lead to problems. It is not a question of if, but when. In the time it
takes you to figure this out, you can probably replace the TCursor with
a Firebird stored procedure using SQL which will work reliably every
time. Probably not what you wanted to hear, but I believe it is by far
the best way to go.

Regards,
RoyF



Gene De Guzman wrote:

This sounds like the server is disconnecting from the Paradox session.
Have you updated your Firebird software?

Now, I trust you're not going to say that you're using the native BDE
Interbase SQL Link to access a Firebird database using a TCursor.
Because if you are then you are boldly walking into the cavern of a
vicious, fiery dragon without armour or a sword and not even your faith
in all things good will save you.

I can't stress enough that direct access to SQL server tables in Paradox
will cause grief. Tcursors are particularly prone to causing problems.
If you access a Firebird database using the native Interbase link well,
Firebird's had numerous releases and updates since the Interbase 6
code-base turned into Firebird 0.0.1 so something MUST have changed.

You will eventually confront the reasons why everyone says not to do it.

Gene De Guzman wrote:
Tom Krieg

---------------
http://www.krieg.com.au
Please use the contact page to contact me via email

This sounds like the server is disconnecting from the Paradox session.
Have you updated your Firebird software?

Now, I trust you're not going to say that you're using the native BDE
Interbase SQL Link to access a Firebird database using a TCursor.
Because if you are then you are boldly walking into the cavern of a
vicious, fiery dragon without armour or a sword and not even your faith
in all things good will save you.

I can't stress enough that direct access to SQL server tables in Paradox
will cause grief. Tcursors are particularly prone to causing problems.
If you access a Firebird database using the native Interbase link well,
Firebird's had numerous releases and updates since the Interbase 6
code-base turned into Firebird 0.0.1 so something MUST have changed.

You will eventually confront the reasons why everyone says not to do it.

Gene De Guzman wrote:
Tom Krieg

---------------
http://www.krieg.com.au
Please use the contact page to contact me via email