Suddenly getting this error in some installations of an application that has been unchanged in the past year.  The exception is happening on multiple tables with the first being a simple "SELECT * FROM TableName".  This is occuring when we are synchronizing the remote installation database with our local database.  

At the same time we have some users that can establish a session with us (TDBISAMSession.Open), and can make the database active (TDBISAMDatabase.Open), but will hang when we try to open a query with a test application (no error returned).  The relevant code for the test application:

   Label1.Caption := 'Connecting session';
   Label1.Refresh;

   sessRemote.Open;

   // Note: We see a session for the User IP address connected on our server here.
   Label1.Caption := 'Connecting to database';
   Label1.Refresh;

   dbRemote.Open;

   Label1.Caption := 'Executing query';
   Label1.Refresh;

   qryRemote.SQL.Text := 'SELECT * FROM TableName WHERE ID=SingleRecordID';
   qryRemote.Open;

   // Never gets here (Label1.Caption = 'Executing query').
   Label1.Caption := 'Completed';
   Label1.Refresh;

Is there an internet routing issue that could cause this kind of thing to happen?

(We are using version 4.16)

Thanks,

Mike

<Michael Mount> wrote in message
news:2A27B45A-FF10-4DEB-8706-8F5E1B354342@news.elevatesoft.com...
>
>    qryRemote.SQL.Text := 'SELECT * FROM TableName WHERE
> ID=SingleRecordID';

What is SingleRecordID?

Robert

Mike,

<< Suddenly getting this error in some installations of an application that
has been unchanged in the past year.  The exception is happening on multiple
tables with the first being a simple "SELECT * FROM TableName".  This is
occuring when we are synchronizing the remote installation database with our
local database. >>

Are you sure that nothing has changed ?  Are you using runtime packages at
all ?

<< At the same time we have some users that can establish a session with us
(TDBISAMSession.Open), and can make the database active
(TDBISAMDatabase.Open), but will hang when we try to open a query with a
test application (no error returned).  The relevant code for the test
application: >>

Most likely this is a firewall or anti-virus issue.

<< (We are using version 4.16) >>

You should definitely consider updating to a later version.  There have been
a very large number of fixes since 4.16.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Robert" wrote:


<Michael Mount> wrote in message
news:2A27B45A-FF10-4DEB-8706-8F5E1B354342@news.elevatesoft.com...
>
>    qryRemote.SQL.Text := 'SELECT * FROM TableName WHERE
> ID=SingleRecordID';

What is SingleRecordID?

Robert

---
Anything - just trying to indicate that the query ewas restricted to return just a single record.

Mike

Tim,

<< Are you sure that nothing has changed ?  Are you using runtime packages at
all ? >>

We are using runtime packages but have not released an update since 4/6/09.  The BPL's are all kept in the application directory.  If the user somehow updated a BPL file it would be replaced back out with the version we originally gave them as part of the upgrade checking system we have built in.

<< Most likely this is a firewall or anti-virus issue. >>

Generally that is true.  In this case we spent a day trying to figure out the firewall/AV issue (since it looks like one) and that is absolutely not it.  At least not at the client site or our site.  NOTE: I just realized that between issuing an SQL statement at getting the parsing error there is a consistent 5 minute delay.  It is possible that my test application wasn't actually hanging and if I'd just waited 5 minutes I'd have gotten the error.

<< You should definitely consider updating to a later version.  There have been
a very large number of fixes since 4.16. >>

So far we have not seen any issues that affect this application on v4.16 so don't see a need to update yet.

Thanks,

Mike

As a side note we've been running tracert's on the IP addresses we're having problems with and all of them are going through one common IP address at Time Warner.  We ran an internet latency check (via an internet website) across that address and it is showing a 62% packet loss.  Would that loss be enough to cause odd problems like we're seeing here in the DBISAM communication link?

Thanks,

Mike

Update 3/5/10:

I let the test application that I thought was just hanging run longer and it does return the duplicate table error eventually.  I changed the SQL statement to query a database table with one record and one field (integer) and got the same duplicate table error.

The SQL statement I'm executing in the test application now is "SELECT * FROM Dummy WHERE ID=1" and the error says the duplicate name is at line 1, column 15.  Is there some way that I can see the actual SQL statement the server is seeing?  

To work around the issue we have set up another DBISAM server on our backup cable modem ISP.  The users having the problems do not have them anymore on that other ISP line (which is not routing through twtelecom servers).  This is without a doubt an internet routing issue of some kind.

I'd like to know what kind of routing issue might cause the SQL parsing error.  Any ideas?

Thanks,

Mike

Michael,

<< I let the test application that I thought was just hanging run longer and
it does return the duplicate table error eventually.  I changed the SQL
statement to query a database table with one record and one field (integer)
and got the same duplicate table error.

The SQL statement I'm executing in the test application now is "SELECT *
FROM Dummy WHERE ID=1" and the error says the duplicate name is at line 1,
column 15.  Is there some way that I can see the actual SQL statement the
server is seeing? >>

You're seeing it.  Unless you use parameters, the SQL statement that the
server executes is exactly what you sent it.

<< I'd like to know what kind of routing issue might cause the SQL parsing
error.  Any ideas? >>

A routing issue can't cause an SQL parsing error.  At best, it can cause a
slowdown.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< You're seeing it.  Unless you use parameters, the SQL statement that the
server executes is exactly what you sent it. >>

So, if I'm sending "SELECT * FROM Dummy WHERE ID=1" and that's exactly what the server is seeing how could I be getting the duplicate table error?  Is it somehow the wrong error message?  Could the 5 minute-ish delay in getting the error explain anything (like maybe we aren't really getting an error back but since we don't get data either that is the default message)?

<< A routing issue can't cause an SQL parsing error.  At best, it can cause a
slowdown. >>

What if a router somewhere along the line is actually mangling the packets somehow?  Or is duplicating packets somehow?  We did see one tracert that showed the exact same IP address on two consecutive lines (I hadn't seen that before in a tracert but don't know if it can be normal).

Thanks,

Mike

Michael,

<< So, if I'm sending "SELECT * FROM Dummy WHERE ID=1" and that's exactly
what the server is seeing how could I be getting the duplicate table error?
>>

I don't know, but I doubt very much that it is being caused by the comms
layer.  My understanding of TCP/IP is that it is impossible to get a
malformed stream on the receiving end due to integrity checks on the
packets.

<< Is it somehow the wrong error message?  Could the 5 minute-ish delay in
getting the error explain anything (like maybe we aren't really getting an
error back but since we don't get data either that is the default message)?
>>

No, it's not the default message.

Did you try this with DBSYS, just to eliminate the possibility of a coding
error or something similar ?

<< What if a router somewhere along the line is actually mangling the
packets somehow?  Or is duplicating packets somehow?  We did see one tracert
that showed the exact same IP address on two consecutive lines (I hadn't
seen that before in a tracert but don't know if it can be normal). >>

Again, I highly doubt it.  I've been doing this for many years, and I've
never seen such a thing.  That doesn't mean that it's impossible, but it is
very unlikely.

--
Tim Young
Elevate Software
www.elevatesoft.com