Not sure where to put this--strange ODBC behavior (or I think it's strange)

Not sure where to put this--strange ODBC behavior (or I think it's strange)

Post by Brent Whit » Sat, 18 May 2002 02:17:00

I have a database that writes to a SQL 7 table through
ODBC (Access 2000).  The main server went down and we were
able to, relatively quickly, move to the backup server
(I'd been making backups all along and storing them off
the main database server, so it wasn't a problem to
retrieve them).

All was working well with the backup server, despite it
being slower than molasses in winter, and we finally got
the main server back up.  In the meantime, the Acc 2000
application was used again.  I didn't change the server
name to the main server (it had been on the backup
server's name), but all of a sudden I saw that data was
being written to the main server again.  How could this be
without me changing anything on the client machine (I did
change my machine back to point to the main server, but
not the machine from which the client application runs)?  
The client app had been writing to the backup server.

We are using TCP/IP connectivity, no cluster services,
with the SQL 7 Driver for ODBC, to connect between the
client and the server.  I specified the machine name MAIL1
(the backup server) for the ODBC data source.

The problem with all of this is that the client seems to
be going back to the server before I get a chance to
restore from backup (so that the data that was written to
the backup server is now in the main server), and this
causes problems going forward.


1. Strange error creating index - not sure I understand what's gone wrong

Hi all,

I'm getting the following error trying to create an index:

ERROR state: S1000(1763) Error:  [INTERSOLV][ODBC SQL Server
driver][SQL Server]Cannot insert rows into sysstatistics, due to
multiple equal frequency values, please contact Sybase Technical

The index statement is

create unique index accname on name (accname, pkcode)

At first I thought - OK, the unique index can't be created because of
duplicate keys - but taking out the unique keyword gives the same
error.  Any ideas out there?


2. Two-way replication with Microsoft SQL Server 6.5

3. Strange GetChunk Put Behavior

4. SQL 6.5 backup

5. Strange behavior using Perl's system() function to query SQL Server with osql

6. Help!!! - VBDB32.DLL

7. Strange behavior on multiple primary key behavior d

8. Wrapping Detail Records

9. Strange behavior on multiple primary key behavior

10. Strange behavior on multiple primary key behavior deleting childr

11. Strange SP behavior, not recognizing index

12. Strange behavior of "Not In" clause

13. Very strange behavior with SQL2000 / ODBC / VC++6 - Transactions