I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
records in the linked table they come up fine, but after about 30
seconds it dings and i get the pop up ODBC--call failed. If i close the
form and reopen it, the records are there again, but the connection
drops again in another 30 seconds.
I'm stumped here because my connection does work, it just keeps
dropping.
Any help or ideas would be greatly appreciated.
Thanks!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
What happens if after you open the form, you go to the last
record and then go about and do whatever with the form? Does
the same thing still happen?
ODBC call failed can happen for a lot of different reasons.
A good way to track them down is to turn on ODBC tracing to
look for specific errors. You would want to make sure to
turn it back off after you get the error as it will really
slow things down.
To turn on tracing, go to the ODBC Data Source Administrator
applet and go to the tracing tab. Just click on start
tracing now and note the location for the trace file. After
you hit the error, go back and click on the stop tracing now
button. Then you can go to the trace file and see what other
information you can get out of the trace file.
-Sue
On Thu, 13 Jan 2005 13:19:15 -0800, vespo
<anonymous@.devdex.com> wrote:
>
>I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
>via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
>records in the linked table they come up fine, but after about 30
>seconds it dings and i get the pop up ODBC--call failed. If i close the
>form and reopen it, the records are there again, but the connection
>drops again in another 30 seconds.
>I'm stumped here because my connection does work, it just keeps
>dropping.
>Any help or ideas would be greatly appreciated.
>Thanks!
>Vicki
>*** Sent via Developersdex http://www.codecomments.com ***
>Don't just participate in USENET...get rewarded for it!
|||Thanks Sue!
That ODBC Trace really helped! It turns out it is an issue with Access
97 where even if you bracket an alias fieldname in a SQL View, it
considers reserved words as reserved words and can't bring them across.
I was trying to enable my client the usage of their old Access 97 forms
and reports by linking to the data i migrated into SQL, so to do that i
had created a view that mimicked their old fields names ("Phone Number",
"Date Updated", etc) and had no problems staying connected when i tried
it on my server (which has Access 2000) but unfortunately my client
isn't ready to upgrade their Access version.
Oddly though -- reports will work in Access 97 using the reserved field
name, it's just the forms and opening the table directly which caused
the ODBC to drop.
Thanks again!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Showing posts with label pro. Show all posts
Showing posts with label pro. Show all posts
Monday, March 12, 2012
ODBC--call failed
I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
records in the linked table they come up fine, but after about 30
seconds it dings and i get the pop up ODBC--call failed. If i close the
form and reopen it, the records are there again, but the connection
drops again in another 30 seconds.
I'm stumped here because my connection does work, it just keeps
dropping.
Any help or ideas would be greatly appreciated.
Thanks!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!What happens if after you open the form, you go to the last
record and then go about and do whatever with the form? Does
the same thing still happen?
ODBC call failed can happen for a lot of different reasons.
A good way to track them down is to turn on ODBC tracing to
look for specific errors. You would want to make sure to
turn it back off after you get the error as it will really
slow things down.
To turn on tracing, go to the ODBC Data Source Administrator
applet and go to the tracing tab. Just click on start
tracing now and note the location for the trace file. After
you hit the error, go back and click on the stop tracing now
button. Then you can go to the trace file and see what other
information you can get out of the trace file.
-Sue
On Thu, 13 Jan 2005 13:19:15 -0800, vespo
<anonymous@.devdex.com> wrote:
>
>I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
>via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
>records in the linked table they come up fine, but after about 30
>seconds it dings and i get the pop up ODBC--call failed. If i close the
>form and reopen it, the records are there again, but the connection
>drops again in another 30 seconds.
>I'm stumped here because my connection does work, it just keeps
>dropping.
>Any help or ideas would be greatly appreciated.
>Thanks!
>Vicki
>*** Sent via Developersdex http://www.codecomments.com ***
>Don't just participate in USENET...get rewarded for it!|||Thanks Sue!
That ODBC Trace really helped! It turns out it is an issue with Access
97 where even if you bracket an alias fieldname in a SQL View, it
considers reserved words as reserved words and can't bring them across.
I was trying to enable my client the usage of their old Access 97 forms
and reports by linking to the data i migrated into SQL, so to do that i
had created a view that mimicked their old fields names ("Phone Number",
"Date Updated", etc) and had no problems staying connected when i tried
it on my server (which has Access 2000) but unfortunately my client
isn't ready to upgrade their Access version.
Oddly though -- reports will work in Access 97 using the reserved field
name, it's just the forms and opening the table directly which caused
the ODBC to drop.
Thanks again!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
records in the linked table they come up fine, but after about 30
seconds it dings and i get the pop up ODBC--call failed. If i close the
form and reopen it, the records are there again, but the connection
drops again in another 30 seconds.
I'm stumped here because my connection does work, it just keeps
dropping.
Any help or ideas would be greatly appreciated.
Thanks!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!What happens if after you open the form, you go to the last
record and then go about and do whatever with the form? Does
the same thing still happen?
ODBC call failed can happen for a lot of different reasons.
A good way to track them down is to turn on ODBC tracing to
look for specific errors. You would want to make sure to
turn it back off after you get the error as it will really
slow things down.
To turn on tracing, go to the ODBC Data Source Administrator
applet and go to the tracing tab. Just click on start
tracing now and note the location for the trace file. After
you hit the error, go back and click on the stop tracing now
button. Then you can go to the trace file and see what other
information you can get out of the trace file.
-Sue
On Thu, 13 Jan 2005 13:19:15 -0800, vespo
<anonymous@.devdex.com> wrote:
>
>I have an Access 97 database (using Jet 4.0) connecting to a SQL 2000
>via ODBC - the OS is Win XP Pro SP2. When i open a form to display the
>records in the linked table they come up fine, but after about 30
>seconds it dings and i get the pop up ODBC--call failed. If i close the
>form and reopen it, the records are there again, but the connection
>drops again in another 30 seconds.
>I'm stumped here because my connection does work, it just keeps
>dropping.
>Any help or ideas would be greatly appreciated.
>Thanks!
>Vicki
>*** Sent via Developersdex http://www.codecomments.com ***
>Don't just participate in USENET...get rewarded for it!|||Thanks Sue!
That ODBC Trace really helped! It turns out it is an issue with Access
97 where even if you bracket an alias fieldname in a SQL View, it
considers reserved words as reserved words and can't bring them across.
I was trying to enable my client the usage of their old Access 97 forms
and reports by linking to the data i migrated into SQL, so to do that i
had created a view that mimicked their old fields names ("Phone Number",
"Date Updated", etc) and had no problems staying connected when i tried
it on my server (which has Access 2000) but unfortunately my client
isn't ready to upgrade their Access version.
Oddly though -- reports will work in Access 97 using the reserved field
name, it's just the forms and opening the table directly which caused
the ODBC to drop.
Thanks again!
Vicki
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Wednesday, March 7, 2012
ODBC System DSN Questions
We are running an SBS2000 network with around 40 clients being 60% Windows
2000 Pro and 40% WinXP Pro. We have around 3 member servers (not DC) and one
of the servers is a SQL server running SQL 2000.
A user on the domain has created a dBasev5.7 form that needs an ODBC System
DSN connection from the client to the SQL server in order for his form to be
populated with data. He wanted to roll out the DSNs to all the machines on
the network via Group Policy - I did a bit of digging around in the
Newsgroups and someone suggested this automated way by running a vbs script:
http://www.databasejournal.com/featu...e.php/2238221. Although
this works - we have a slight problem. We have no idea if this is to do with
dBase (it uses 16-bit architecture) but when we roll out the DSNs using the
script the registry gets updated (HKEYLOCAL
MACHINE>SOFTWARE>ODBC>ODBC.INI...) with all the right keys (as if you set it
up manually in Control Panel's ODBC) but we need to go through the System DSN
wizard (to the last page of the wizard) and click the "Test connection"
button in order for the dBase program to access the ODBC database connection.
It seems as if the ODBC System DSN is dead without clicking the "Test
Connection" button.
Questions:
1. Is it a requirement to hit the Test Network Connection button on the
last page of the wizard. I thought that this was only for troubleshooting?
2. It appears that this "Test Connection" button in the wizard posts a
registry key to allow the ODBC SYstem DSN (it has created) to be used. Where
abouts is this registry key?
3. Is there a Group Policy way of doing this? Chances are we may change
settings in the future and may want a server-side script running to update
any changes to clients automatically.
Please help.
THanks,
Skc
I am not usre why this is happening, but I can tell you that the Test
Connection button does not write a registry entry anywhere. It is just used
for testing the connection. Possibly teh script leaves something out that
is necessary and going through the wizard completes the process.
It is possible that an alias to the SQL Server is geing created when the
wizard is accessed. There is a cliconfg tuiltiy that you can use to verify
this.
Run the script on a client machine and then run cliconfg from Start - Run.
Check the alias tab to see if there is an alias to this SQL Server. If not,
then run the Wizard and go through the steps. After it completes go back to
cliconfg and see if there is an alias. In many case the cliconfg utility
will create an alias or a SQL Server when a DSN has been created.
Rand
This posting is provided "as is" with no warranties and confers no rights.
2000 Pro and 40% WinXP Pro. We have around 3 member servers (not DC) and one
of the servers is a SQL server running SQL 2000.
A user on the domain has created a dBasev5.7 form that needs an ODBC System
DSN connection from the client to the SQL server in order for his form to be
populated with data. He wanted to roll out the DSNs to all the machines on
the network via Group Policy - I did a bit of digging around in the
Newsgroups and someone suggested this automated way by running a vbs script:
http://www.databasejournal.com/featu...e.php/2238221. Although
this works - we have a slight problem. We have no idea if this is to do with
dBase (it uses 16-bit architecture) but when we roll out the DSNs using the
script the registry gets updated (HKEYLOCAL
MACHINE>SOFTWARE>ODBC>ODBC.INI...) with all the right keys (as if you set it
up manually in Control Panel's ODBC) but we need to go through the System DSN
wizard (to the last page of the wizard) and click the "Test connection"
button in order for the dBase program to access the ODBC database connection.
It seems as if the ODBC System DSN is dead without clicking the "Test
Connection" button.
Questions:
1. Is it a requirement to hit the Test Network Connection button on the
last page of the wizard. I thought that this was only for troubleshooting?
2. It appears that this "Test Connection" button in the wizard posts a
registry key to allow the ODBC SYstem DSN (it has created) to be used. Where
abouts is this registry key?
3. Is there a Group Policy way of doing this? Chances are we may change
settings in the future and may want a server-side script running to update
any changes to clients automatically.
Please help.
THanks,
Skc
I am not usre why this is happening, but I can tell you that the Test
Connection button does not write a registry entry anywhere. It is just used
for testing the connection. Possibly teh script leaves something out that
is necessary and going through the wizard completes the process.
It is possible that an alias to the SQL Server is geing created when the
wizard is accessed. There is a cliconfg tuiltiy that you can use to verify
this.
Run the script on a client machine and then run cliconfg from Start - Run.
Check the alias tab to see if there is an alias to this SQL Server. If not,
then run the Wizard and go through the steps. After it completes go back to
cliconfg and see if there is an alias. In many case the cliconfg utility
will create an alias or a SQL Server when a DSN has been created.
Rand
This posting is provided "as is" with no warranties and confers no rights.
ODBC System DSN Questions
We are running an SBS2000 network with around 40 clients being 60% Windows
2000 Pro and 40% WinXP Pro. We have around 3 member servers (not DC) and on
e
of the servers is a SQL server running SQL 2000.
A user on the domain has created a dBasev5.7 form that needs an ODBC System
DSN connection from the client to the SQL server in order for his form to be
populated with data. He wanted to roll out the DSNs to all the machines on
the network via Group Policy - I did a bit of digging around in the
Newsgroups and someone suggested this automated way by running a vbs script:
http://www.databasejournal.com/feat...le.php/2238221. Although
this works - we have a slight problem. We have no idea if this is to do wit
h
dBase (it uses 16-bit architecture) but when we roll out the DSNs using the
script the registry gets updated (HKEYLOCAL
MACHINE>SOFTWARE>ODBC>ODBC.INI...) with all the right keys (as if you set it
up manually in Control Panel's ODBC) but we need to go through the System DS
N
wizard (to the last page of the wizard) and click the "Test connection"
button in order for the dBase program to access the ODBC database connection
.
It seems as if the ODBC System DSN is dead without clicking the "Test
Connection" button.
Questions:
1. Is it a requirement to hit the Test Network Connection button on the
last page of the wizard. I thought that this was only for troubleshooting?
2. It appears that this "Test Connection" button in the wizard posts a
registry key to allow the ODBC SYstem DSN (it has created) to be used. Wher
e
abouts is this registry key?
3. Is there a Group Policy way of doing this? Chances are we may change
settings in the future and may want a server-side script running to update
any changes to clients automatically.
Please help.
THanks,
SkcI am not usre why this is happening, but I can tell you that the Test
Connection button does not write a registry entry anywhere. It is just used
for testing the connection. Possibly teh script leaves something out that
is necessary and going through the wizard completes the process.
It is possible that an alias to the SQL Server is geing created when the
wizard is accessed. There is a cliconfg tuiltiy that you can use to verify
this.
Run the script on a client machine and then run cliconfg from Start - Run.
Check the alias tab to see if there is an alias to this SQL Server. If not,
then run the Wizard and go through the steps. After it completes go back to
cliconfg and see if there is an alias. In many case the cliconfg utility
will create an alias or a SQL Server when a DSN has been created.
Rand
This posting is provided "as is" with no warranties and confers no rights.
2000 Pro and 40% WinXP Pro. We have around 3 member servers (not DC) and on
e
of the servers is a SQL server running SQL 2000.
A user on the domain has created a dBasev5.7 form that needs an ODBC System
DSN connection from the client to the SQL server in order for his form to be
populated with data. He wanted to roll out the DSNs to all the machines on
the network via Group Policy - I did a bit of digging around in the
Newsgroups and someone suggested this automated way by running a vbs script:
http://www.databasejournal.com/feat...le.php/2238221. Although
this works - we have a slight problem. We have no idea if this is to do wit
h
dBase (it uses 16-bit architecture) but when we roll out the DSNs using the
script the registry gets updated (HKEYLOCAL
MACHINE>SOFTWARE>ODBC>ODBC.INI...) with all the right keys (as if you set it
up manually in Control Panel's ODBC) but we need to go through the System DS
N
wizard (to the last page of the wizard) and click the "Test connection"
button in order for the dBase program to access the ODBC database connection
.
It seems as if the ODBC System DSN is dead without clicking the "Test
Connection" button.
Questions:
1. Is it a requirement to hit the Test Network Connection button on the
last page of the wizard. I thought that this was only for troubleshooting?
2. It appears that this "Test Connection" button in the wizard posts a
registry key to allow the ODBC SYstem DSN (it has created) to be used. Wher
e
abouts is this registry key?
3. Is there a Group Policy way of doing this? Chances are we may change
settings in the future and may want a server-side script running to update
any changes to clients automatically.
Please help.
THanks,
SkcI am not usre why this is happening, but I can tell you that the Test
Connection button does not write a registry entry anywhere. It is just used
for testing the connection. Possibly teh script leaves something out that
is necessary and going through the wizard completes the process.
It is possible that an alias to the SQL Server is geing created when the
wizard is accessed. There is a cliconfg tuiltiy that you can use to verify
this.
Run the script on a client machine and then run cliconfg from Start - Run.
Check the alias tab to see if there is an alias to this SQL Server. If not,
then run the Wizard and go through the steps. After it completes go back to
cliconfg and see if there is an alias. In many case the cliconfg utility
will create an alias or a SQL Server when a DSN has been created.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Saturday, February 25, 2012
ODBC SQL Driver Timeout Expired from MS Access
Hi
I'm running a machine with windows xp pro sp2. I have a MS Access 2000 database on that machine. The database contains 1 odbc linked table
and 1 Access query.
The odbc linked table is connected to a MS SQL Server 2000 database with a ODBC SQL Server System DSN.
The table on SQL Server to which the table in Access is linked has about
3 million + rows.
When I open the ODBC linked table in Access, it opens without a problem.
However, if I use even so much as one criterion such as "where company = ABC" for example, then it "thinks" for a while and returns the dreaded:
[Microsoft][ODBC SQL Driver] Timeout Expired (#0).
I have to use MS Access 2000 as the front end for this SQL Database table.
How do I get around the timeout issue. Is there a setting in SQL?
Please keep in mind that
I can't write the queries as Store procs because the requirement of the client is that there be one Linked Access table that the users can use
to write various access queries. No user are not techies.
please helpread this post:
http://www.mcse.ms/message1582144.html
I don't test.
Tell me.
Bye.
I'm running a machine with windows xp pro sp2. I have a MS Access 2000 database on that machine. The database contains 1 odbc linked table
and 1 Access query.
The odbc linked table is connected to a MS SQL Server 2000 database with a ODBC SQL Server System DSN.
The table on SQL Server to which the table in Access is linked has about
3 million + rows.
When I open the ODBC linked table in Access, it opens without a problem.
However, if I use even so much as one criterion such as "where company = ABC" for example, then it "thinks" for a while and returns the dreaded:
[Microsoft][ODBC SQL Driver] Timeout Expired (#0).
I have to use MS Access 2000 as the front end for this SQL Database table.
How do I get around the timeout issue. Is there a setting in SQL?
Please keep in mind that
I can't write the queries as Store procs because the requirement of the client is that there be one Linked Access table that the users can use
to write various access queries. No user are not techies.
please helpread this post:
http://www.mcse.ms/message1582144.html
I don't test.
Tell me.
Bye.
Subscribe to:
Posts (Atom)