Hello everyone,
One of our applications was timing out while executing a certain
stored procedure that inserts information in a group of tables.
When I checked the situation via Profiler, that particular SP has
indeed an almost consistent duration of roughly 30 seconds (which was
the timeout setting at the frontend).
I copied one of the textdata entry captured in Profiler and executed
this in QA. This executed for almost 2 minutes after which all
subsequent executions of this stored procedure via the application
returned to normal with a duration of about 5 to 10ms.
Has anyone had a similar experience? I am at a loss at what happened,
and I don't know where to begin looking for the cause as it has
resolved itself when I was just attempting to look into it.
Thanks.
AramidIt could be that the auto update stats kicked in, or that the data was
readily available in cache. Do check in Profiler to see if there are any
recompilations. Also capture the execution plan in Profiler, and compare
with the one you are getting in Query Analyzer. It would also help if you
had posted the stored procedure code, so that we can point out any issues.
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"aramid" <aramid@.hotmail.com> wrote in message
news:v5s371p46il11k82jn9tene1701fmtad2j@.
4ax.com...
Hello everyone,
One of our applications was timing out while executing a certain
stored procedure that inserts information in a group of tables.
When I checked the situation via Profiler, that particular SP has
indeed an almost consistent duration of roughly 30 seconds (which was
the timeout setting at the frontend).
I copied one of the textdata entry captured in Profiler and executed
this in QA. This executed for almost 2 minutes after which all
subsequent executions of this stored procedure via the application
returned to normal with a duration of about 5 to 10ms.
Has anyone had a similar experience? I am at a loss at what happened,
and I don't know where to begin looking for the cause as it has
resolved itself when I was just attempting to look into it.
Thanks.
Aramidsql
Showing posts with label applications. Show all posts
Showing posts with label applications. Show all posts
Wednesday, March 21, 2012
Monday, March 19, 2012
ODBC--update on a linked table table_name failed
Hi all,
Hope someone can help me with this one. Thanks in advance.
We have several Access 97 .mdb front-end applications running against an SQL Server 7 database on NT 4.0. I know, welcome to the way back machine. Any way, all was well and running great. Then the user attempted to run the application, it had been successfully run several times earlier in the day, and received the following error: "ODBC--update on linked table 'table_name' failed (Error 3157)". Everything I know suggests that this would be an MDAC version issue except for the abrupt change. From everything I can tell nothing was altered on the hosting server and we are running MDAC 2.5. I have performed the following tests using several different client systems, 98 and 2K, to no avail.
1. Cycled the power on the client and server systems.
2. Opened the linked table in data view mode and attempted to update a single column within a single row.
3. Created new DSN and re-linked tables.
4. Reloaded MDAC 2.5 on both client and server systems.
This only affects Access 97 clients though. If I create an Access 2K database and link to the same server/database/table the updates work just fine.
Any suggestions would be greatly appreciated.
Thanks,
RickHave you tried to update it to Mdac 2.7. This might resolve the issue.|||Originally posted by oj_n
Have you tried to update it to Mdac 2.7. This might resolve the issue.
I'm in the process of testing with the latest MDAC and ODBC drivers now. What I'm realy curious about though is the fact that this was running fine and then just quit. I have suspicions that something was altered on the server but I can't discover what it was and can't get anyone to admit to it. {;^>}
I know when I talk about Access 97, SQL 7 and MDAC 2.5 that it's all history. It's just the nature of the company I'm doing the work for. I'm just a contractor here. We have just migrated their, near 1 GB, Access 97 application/database to SQL server 7, 7 due to licensing issues, and Access 2000. However some front-end apps are still in Access 97. So they are pretty far behind the technology curve.
Thanks for the suggestion; I'll let you know how it turns out.
Thanks,
Rick|||Just in case anyone has the same problem described in my original post:
I discovered the cause and, as I suspected, it was from someone making a change to the SQL Server configuration. The User Option option had been modified to turn the NOCOUNT attribute on. Once I found this I was able to duplicate or fix the problem on a test SQL Server instance. I assume it has to do with Access 97 requireing a row count be returned from SQL Server through ODBC. Don't know exactly why.... yet.
Thanks,
Rick|||you can have better peformance, better flexibility, easier development
and a solution that will work for the next 10 years
if you just throw out Access 97 and convert everything to Access 2002 ADP Format.
Its a thin client to SQL Server.
and it ROCKS!!!
Hope someone can help me with this one. Thanks in advance.
We have several Access 97 .mdb front-end applications running against an SQL Server 7 database on NT 4.0. I know, welcome to the way back machine. Any way, all was well and running great. Then the user attempted to run the application, it had been successfully run several times earlier in the day, and received the following error: "ODBC--update on linked table 'table_name' failed (Error 3157)". Everything I know suggests that this would be an MDAC version issue except for the abrupt change. From everything I can tell nothing was altered on the hosting server and we are running MDAC 2.5. I have performed the following tests using several different client systems, 98 and 2K, to no avail.
1. Cycled the power on the client and server systems.
2. Opened the linked table in data view mode and attempted to update a single column within a single row.
3. Created new DSN and re-linked tables.
4. Reloaded MDAC 2.5 on both client and server systems.
This only affects Access 97 clients though. If I create an Access 2K database and link to the same server/database/table the updates work just fine.
Any suggestions would be greatly appreciated.
Thanks,
RickHave you tried to update it to Mdac 2.7. This might resolve the issue.|||Originally posted by oj_n
Have you tried to update it to Mdac 2.7. This might resolve the issue.
I'm in the process of testing with the latest MDAC and ODBC drivers now. What I'm realy curious about though is the fact that this was running fine and then just quit. I have suspicions that something was altered on the server but I can't discover what it was and can't get anyone to admit to it. {;^>}
I know when I talk about Access 97, SQL 7 and MDAC 2.5 that it's all history. It's just the nature of the company I'm doing the work for. I'm just a contractor here. We have just migrated their, near 1 GB, Access 97 application/database to SQL server 7, 7 due to licensing issues, and Access 2000. However some front-end apps are still in Access 97. So they are pretty far behind the technology curve.
Thanks for the suggestion; I'll let you know how it turns out.
Thanks,
Rick|||Just in case anyone has the same problem described in my original post:
I discovered the cause and, as I suspected, it was from someone making a change to the SQL Server configuration. The User Option option had been modified to turn the NOCOUNT attribute on. Once I found this I was able to duplicate or fix the problem on a test SQL Server instance. I assume it has to do with Access 97 requireing a row count be returned from SQL Server through ODBC. Don't know exactly why.... yet.
Thanks,
Rick|||you can have better peformance, better flexibility, easier development
and a solution that will work for the next 10 years
if you just throw out Access 97 and convert everything to Access 2002 ADP Format.
Its a thin client to SQL Server.
and it ROCKS!!!
Monday, March 12, 2012
ODBC Write Failures
I've got an odd occasonal problem when writing to our server. In two
different applications, one an access app, and the other VB6 we will
experience a condition where we are able to read data, but when we attempt
to save the data we get ODBC timeouts. When this occurs, I can "fix" the
problem by going into one of the tables of the database in question and
modifying any value.
Configuration is a dual Xeon with 2gb of memory running SQL Server 2000.
Both databases are on this system and are accessed via different DSNs. One
is a web app, and is accessed by com dlls, the other is an app that was
created in MS Access and then modified so that it gets its data from linked
tables.
Any insite, or even better a good description of troublshooting techniques
would be appreciated.
Sam RobinsonHi Sam,
According to your description, I am not sure what your problem is. I would
like you to provide the following information so that I can narrow down
this issue.
1. Please provide me with the detailed error message. To do this, you can
take a screenshot. Please send it to me at v-yshao@.microsoft.com. For
additional information regarding how to obtain the screen shot, please
review [Item 1].
2. How did you read and write data with Access to SQL Server, via a linked
table or programming? Can you describe it in detailed?
3. I would like to know when the error occurred. It seems that the error
occurred when you updated the table on SQL Server. Did the error message
occur when you connected to SQL Server?
4. When the error occurs again, please perform the problematic SQL
statements using Query Analyzer. Does the same error message occur again?
It helps us to identify the problem related to the SQL Server including SQL
statements and your VB code.
5. Please provide the SQL Server error log (usually under C:\Program
Files\Microsoft SQL Server\MSSQL\LOG)
On the SQL Server side, there is a query wait option. This query wait
option helps us specify the time in seconds (from 0 through 2147483647)
that a query waits for resources before timing out. We can increase the
value of this option trying to avoid the timeout error message. For
additional information regarding this query wait option, please refer to
the following article on SQL Server Books Online.
Topic: "query wait Option"
Also, such issues occurring randomly tend to be complex and take up
extensive research time. I'd like to set your expectations that it may take
a while for us to help you narrow down the problem and we may eventually
redirect you to PSS to continue working with a dedicated Support
Professional. If this is critical, I'd recommend contacting PSS and opening
a support incident troubleshoot this further. If you need any help in this
regard, please let me know.
[Item 1]
Try to obtain the screen shot of the error message.
When the error occurred please perform the following steps to capture the
screen shot of the error message.
1. Press the "Pr Scrn" button on the keyboard.
2. Run the Paint tools (Start 'All programs 'Accessories ' Paint).
3. Press Ctrl+V to copy the screen shot from the memory.
4. Save as a JPEG file.
Thank you for using MSDN newsgroup.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:2tLJaornDHA.2148@.cpmsftngxa06.phx.gbl...
> Hi Sam,
> According to your description, I am not sure what your problem is. I would
> like you to provide the following information so that I can narrow down
> this issue.
> 1. Please provide me with the detailed error message. To do this, you can
> take a screenshot. Please send it to me at v-yshao@.microsoft.com. For
> additional information regarding how to obtain the screen shot, please
> review [Item 1].
>
I assume that you're referring to the error message that is being seen in
access. These are not terribly informative, and do not provide error
numbers. The errors being returned to the web app (which seems to have
somewhat better error handling) are timeouts.
> 2. How did you read and write data with Access to SQL Server, via a
linked
> table or programming? Can you describe it in detailed?
>
Access is using linked tables. These were created using the standard table
linking wizard from the file menu.
> 3. I would like to know when the error occurred. It seems that the error
> occurred when you updated the table on SQL Server. Did the error message
> occur when you connected to SQL Server?
>
No, it didn't. The applications are still able to read data when this
happens, which is what has me foxed. The connection seems to be almost
healthy.
> 4. When the error occurs again, please perform the problematic SQL
> statements using Query Analyzer. Does the same error message occur again?
> It helps us to identify the problem related to the SQL Server including
SQL
> statements and your VB code.
>
Unfortunately, the same SQL statements succeed more often than not.
> 5. Please provide the SQL Server error log (usually under C:\Program
> Files\Microsoft SQL Server\MSSQL\LOG)
>
I can certainly do this, but what I'm seeing there is just that the backups
ran correctly.
> On the SQL Server side, there is a query wait option. This query wait
> option helps us specify the time in seconds (from 0 through 2147483647)
> that a query waits for resources before timing out. We can increase the
> value of this option trying to avoid the timeout error message. For
> additional information regarding this query wait option, please refer to
> the following article on SQL Server Books Online.
> Topic: "query wait Option"
> Also, such issues occurring randomly tend to be complex and take up
> extensive research time. I'd like to set your expectations that it may
take
> a while for us to help you narrow down the problem and we may eventually
> redirect you to PSS to continue working with a dedicated Support
> Professional. If this is critical, I'd recommend contacting PSS and
opening
> a support incident troubleshoot this further. If you need any help in this
> regard, please let me know.
>
I did find that the transaction logs had grown to truly monumental sizes (18
and 15 gb respectively) I cleaned that up last night, and am watching the
system. Does this seem like a likely culprit? I know that the log is broken
into virtual segments, but if the segment count gets very high can this
cause long lookup/write times that might impact external timers?
I can certainly appreciate your comments regarding intermittent problems and
how difficult they can be to resolve... or even to know if they're resolved.
I'm mostly looking for an approach to troubleshooting, and your posting has
given me several ideas.
Thanks for the help. As I see the problem (or don't as I'm hoping for!) I'll
post more information.
Sam Robinson|||Hi Sam,
Thanks for your feedback. Based on my experience, when server is busy, such
as performing many jobs on the background, the timeout error will occur.
According to your description with the monumental sizes of transaction
logs, it is possible that there are many jobs working on the background,
such as backup jobs, which impact the performance of the server. Because
the error occurs randomly, it is hard to us to find out the root cause of
this problem. When the error occurs again on your side, please feel free to
post in the newsgroup, I will glad to work with you continously. Of course,
I also hope it do not occur again.
Thanks for using MSDN newsgroup.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:%239I3130nDHA.2464@.cpmsftngxa06.phx.gbl...
> Hi Sam,
> Thanks for your feedback. Based on my experience, when server is busy,
such
> as performing many jobs on the background, the timeout error will occur.
> According to your description with the monumental sizes of transaction
> logs, it is possible that there are many jobs working on the background,
> such as backup jobs, which impact the performance of the server. Because
> the error occurs randomly, it is hard to us to find out the root cause of
> this problem. When the error occurs again on your side, please feel free
to
> post in the newsgroup, I will glad to work with you continously. Of
course,
> I also hope it do not occur again.
> Thanks for using MSDN newsgroup.
>
Michael, et al
Well, it's been a week now and I think it's safe to say that truncating and
setting up a backup maintenance plan has resolved the problem. My
speculation is that the problem came from the necessity to log the
transaction in the increadably huge transaction log. This would seem to
follow as we didn't get a timeout when reading, only when trying to commit a
record.
Wow. Given the size the logs had gotten, I'm amazed that the thing was
working as well as it was.
Thanks for your help!
Sam Robinson
different applications, one an access app, and the other VB6 we will
experience a condition where we are able to read data, but when we attempt
to save the data we get ODBC timeouts. When this occurs, I can "fix" the
problem by going into one of the tables of the database in question and
modifying any value.
Configuration is a dual Xeon with 2gb of memory running SQL Server 2000.
Both databases are on this system and are accessed via different DSNs. One
is a web app, and is accessed by com dlls, the other is an app that was
created in MS Access and then modified so that it gets its data from linked
tables.
Any insite, or even better a good description of troublshooting techniques
would be appreciated.
Sam RobinsonHi Sam,
According to your description, I am not sure what your problem is. I would
like you to provide the following information so that I can narrow down
this issue.
1. Please provide me with the detailed error message. To do this, you can
take a screenshot. Please send it to me at v-yshao@.microsoft.com. For
additional information regarding how to obtain the screen shot, please
review [Item 1].
2. How did you read and write data with Access to SQL Server, via a linked
table or programming? Can you describe it in detailed?
3. I would like to know when the error occurred. It seems that the error
occurred when you updated the table on SQL Server. Did the error message
occur when you connected to SQL Server?
4. When the error occurs again, please perform the problematic SQL
statements using Query Analyzer. Does the same error message occur again?
It helps us to identify the problem related to the SQL Server including SQL
statements and your VB code.
5. Please provide the SQL Server error log (usually under C:\Program
Files\Microsoft SQL Server\MSSQL\LOG)
On the SQL Server side, there is a query wait option. This query wait
option helps us specify the time in seconds (from 0 through 2147483647)
that a query waits for resources before timing out. We can increase the
value of this option trying to avoid the timeout error message. For
additional information regarding this query wait option, please refer to
the following article on SQL Server Books Online.
Topic: "query wait Option"
Also, such issues occurring randomly tend to be complex and take up
extensive research time. I'd like to set your expectations that it may take
a while for us to help you narrow down the problem and we may eventually
redirect you to PSS to continue working with a dedicated Support
Professional. If this is critical, I'd recommend contacting PSS and opening
a support incident troubleshoot this further. If you need any help in this
regard, please let me know.
[Item 1]
Try to obtain the screen shot of the error message.
When the error occurred please perform the following steps to capture the
screen shot of the error message.
1. Press the "Pr Scrn" button on the keyboard.
2. Run the Paint tools (Start 'All programs 'Accessories ' Paint).
3. Press Ctrl+V to copy the screen shot from the memory.
4. Save as a JPEG file.
Thank you for using MSDN newsgroup.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:2tLJaornDHA.2148@.cpmsftngxa06.phx.gbl...
> Hi Sam,
> According to your description, I am not sure what your problem is. I would
> like you to provide the following information so that I can narrow down
> this issue.
> 1. Please provide me with the detailed error message. To do this, you can
> take a screenshot. Please send it to me at v-yshao@.microsoft.com. For
> additional information regarding how to obtain the screen shot, please
> review [Item 1].
>
I assume that you're referring to the error message that is being seen in
access. These are not terribly informative, and do not provide error
numbers. The errors being returned to the web app (which seems to have
somewhat better error handling) are timeouts.
> 2. How did you read and write data with Access to SQL Server, via a
linked
> table or programming? Can you describe it in detailed?
>
Access is using linked tables. These were created using the standard table
linking wizard from the file menu.
> 3. I would like to know when the error occurred. It seems that the error
> occurred when you updated the table on SQL Server. Did the error message
> occur when you connected to SQL Server?
>
No, it didn't. The applications are still able to read data when this
happens, which is what has me foxed. The connection seems to be almost
healthy.
> 4. When the error occurs again, please perform the problematic SQL
> statements using Query Analyzer. Does the same error message occur again?
> It helps us to identify the problem related to the SQL Server including
SQL
> statements and your VB code.
>
Unfortunately, the same SQL statements succeed more often than not.
> 5. Please provide the SQL Server error log (usually under C:\Program
> Files\Microsoft SQL Server\MSSQL\LOG)
>
I can certainly do this, but what I'm seeing there is just that the backups
ran correctly.
> On the SQL Server side, there is a query wait option. This query wait
> option helps us specify the time in seconds (from 0 through 2147483647)
> that a query waits for resources before timing out. We can increase the
> value of this option trying to avoid the timeout error message. For
> additional information regarding this query wait option, please refer to
> the following article on SQL Server Books Online.
> Topic: "query wait Option"
> Also, such issues occurring randomly tend to be complex and take up
> extensive research time. I'd like to set your expectations that it may
take
> a while for us to help you narrow down the problem and we may eventually
> redirect you to PSS to continue working with a dedicated Support
> Professional. If this is critical, I'd recommend contacting PSS and
opening
> a support incident troubleshoot this further. If you need any help in this
> regard, please let me know.
>
I did find that the transaction logs had grown to truly monumental sizes (18
and 15 gb respectively) I cleaned that up last night, and am watching the
system. Does this seem like a likely culprit? I know that the log is broken
into virtual segments, but if the segment count gets very high can this
cause long lookup/write times that might impact external timers?
I can certainly appreciate your comments regarding intermittent problems and
how difficult they can be to resolve... or even to know if they're resolved.
I'm mostly looking for an approach to troubleshooting, and your posting has
given me several ideas.
Thanks for the help. As I see the problem (or don't as I'm hoping for!) I'll
post more information.
Sam Robinson|||Hi Sam,
Thanks for your feedback. Based on my experience, when server is busy, such
as performing many jobs on the background, the timeout error will occur.
According to your description with the monumental sizes of transaction
logs, it is possible that there are many jobs working on the background,
such as backup jobs, which impact the performance of the server. Because
the error occurs randomly, it is hard to us to find out the root cause of
this problem. When the error occurs again on your side, please feel free to
post in the newsgroup, I will glad to work with you continously. Of course,
I also hope it do not occur again.
Thanks for using MSDN newsgroup.
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||"Michael Shao [MSFT]" <v-yshao@.online.microsoft.com> wrote in message
news:%239I3130nDHA.2464@.cpmsftngxa06.phx.gbl...
> Hi Sam,
> Thanks for your feedback. Based on my experience, when server is busy,
such
> as performing many jobs on the background, the timeout error will occur.
> According to your description with the monumental sizes of transaction
> logs, it is possible that there are many jobs working on the background,
> such as backup jobs, which impact the performance of the server. Because
> the error occurs randomly, it is hard to us to find out the root cause of
> this problem. When the error occurs again on your side, please feel free
to
> post in the newsgroup, I will glad to work with you continously. Of
course,
> I also hope it do not occur again.
> Thanks for using MSDN newsgroup.
>
Michael, et al
Well, it's been a week now and I think it's safe to say that truncating and
setting up a backup maintenance plan has resolved the problem. My
speculation is that the problem came from the necessity to log the
transaction in the increadably huge transaction log. This would seem to
follow as we didn't get a timeout when reading, only when trying to commit a
record.
Wow. Given the size the logs had gotten, I'm amazed that the thing was
working as well as it was.
Thanks for your help!
Sam Robinson
Wednesday, March 7, 2012
ODBC SQLINTEGER & (BADMEM) - Why?
Hi,
I have the ODBC tracing enabled on my development machine using the
"default" tracing DLL.
I thought it was just our applications causing this, but I'm also seeing
this when using isqlw (SQL Query Analyzer).
Is it an issue? The app. seems to have no issues. I know it is indicating
that the memory location is invalid. Why?
I would like to know what the cause is, what other tools are available to
track this down, in the event it is an issue. It doesn't seem like a
"normal" occurrence.
From our app:
12345678.A24 N 95c-cdcEXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS)
SQLHENV 008F1540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER 0
12345678.A24 N 95c-cdcEXIT SQLSetConnectAttr with return code 0
(SQL_SUCCESS)
SQLHDBC 008F15E8
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x0000003C (BADMEM)
SQLINTEGER 0
From ISQLW:
isqlw edc-9c4EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS)
SQLHENV 008D1540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER -5
isqlw edc-9c4EXIT SQLSetConnectAttrW with return code 0
(SQL_SUCCESS)
SQLHDBC 008D15E8
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x0000000F (BADMEM)
SQLINTEGER -5
isqlw edc-9c4EXIT SQLSetStmtAttrW with return code 0
(SQL_SUCCESS)
SQLHSTMT 008D19B8
SQLINTEGER 3 <SQL_ATTR_MAX_LENGTH>
SQLPOINTER 0x0000FC00 (BADMEM)
SQLINTEGER -5
Thanks. Jeff
Hello,
This behavior seems to be normal because some parameters are not used when
calling this method. Also, the SQL_SUCCESS indicate these functions work
fine. For example:
SQLSetConnectAttr Function
http://msdn.microsoft.com/library/de...us/odbc/htm/od
bcsqlsetconnectattr.asp
ValuePtr
[Input]
Pointer to the value to be associated with Attribute. Depending on the
value of Attribute, ValuePtr will be a 32-bit unsigned integer value or
will point to a null-terminated character string. Note that if the
Attribute argument is a driver-specific value, the value in ValuePtr may be
a signed integer.
Sophie Guo
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
I have the ODBC tracing enabled on my development machine using the
"default" tracing DLL.
I thought it was just our applications causing this, but I'm also seeing
this when using isqlw (SQL Query Analyzer).
Is it an issue? The app. seems to have no issues. I know it is indicating
that the memory location is invalid. Why?
I would like to know what the cause is, what other tools are available to
track this down, in the event it is an issue. It doesn't seem like a
"normal" occurrence.
From our app:
12345678.A24 N 95c-cdcEXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS)
SQLHENV 008F1540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER 0
12345678.A24 N 95c-cdcEXIT SQLSetConnectAttr with return code 0
(SQL_SUCCESS)
SQLHDBC 008F15E8
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x0000003C (BADMEM)
SQLINTEGER 0
From ISQLW:
isqlw edc-9c4EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS)
SQLHENV 008D1540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER -5
isqlw edc-9c4EXIT SQLSetConnectAttrW with return code 0
(SQL_SUCCESS)
SQLHDBC 008D15E8
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x0000000F (BADMEM)
SQLINTEGER -5
isqlw edc-9c4EXIT SQLSetStmtAttrW with return code 0
(SQL_SUCCESS)
SQLHSTMT 008D19B8
SQLINTEGER 3 <SQL_ATTR_MAX_LENGTH>
SQLPOINTER 0x0000FC00 (BADMEM)
SQLINTEGER -5
Thanks. Jeff
Hello,
This behavior seems to be normal because some parameters are not used when
calling this method. Also, the SQL_SUCCESS indicate these functions work
fine. For example:
SQLSetConnectAttr Function
http://msdn.microsoft.com/library/de...us/odbc/htm/od
bcsqlsetconnectattr.asp
ValuePtr
[Input]
Pointer to the value to be associated with Attribute. Depending on the
value of Attribute, ValuePtr will be a 32-bit unsigned integer value or
will point to a null-terminated character string. Note that if the
Attribute argument is a driver-specific value, the value in ValuePtr may be
a signed integer.
Sophie Guo
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
================================================== ===
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
ODBC SQLINTEGER & (BADMEM) - Why?
Hi,
I have the ODBC tracing enabled on my development machine using the
"default" tracing DLL.
I thought it was just our applications causing this, but I'm also seeing
this when using isqlw (SQL Query Analyzer).
Is it an issue? The app. seems to have no issues. I know it is indicating
that the memory location is invalid. Why?
I would like to know what the cause is, what other tools are available to
track this down, in the event it is an issue. It doesn't seem like a
"normal" occurrence.
From our app:
12345678.A24 N 95c-cdc EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS
)
SQLHENV 008F1540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER 0
12345678.A24 N 95c-cdc EXIT SQLSetConnectAttr with return code 0
(SQL_SUCCESS)
SQLHDBC 008F15E8
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x0000003C (BADMEM)
SQLINTEGER 0
From ISQLW:
isqlw edc-9c4 EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS
)
SQLHENV 008D1540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER -5
isqlw edc-9c4 EXIT SQLSetConnectAttrW with return code 0
(SQL_SUCCESS)
SQLHDBC 008D15E8
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x0000000F (BADMEM)
SQLINTEGER -5
isqlw edc-9c4 EXIT SQLSetStmtAttrW with return code 0
(SQL_SUCCESS)
SQLHSTMT 008D19B8
SQLINTEGER 3 <SQL_ATTR_MAX_LENGTH>
SQLPOINTER 0x0000FC00 (BADMEM)
SQLINTEGER -5
Thanks. JeffHello,
This behavior seems to be normal because some parameters are not used when
calling this method. Also, the SQL_SUCCESS indicate these functions work
fine. For example:
SQLSetConnectAttr Function
http://msdn.microsoft.com/library/d...-us/odbc/htm/od
bcsqlsetconnectattr.asp
ValuePtr
[Input]
Pointer to the value to be associated with Attribute. Depending on the
value of Attribute, ValuePtr will be a 32-bit unsigned integer value or
will point to a null-terminated character string. Note that if the
Attribute argument is a driver-specific value, the value in ValuePtr may be
a signed integer.
Sophie Guo
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
========================================
=============
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
I have the ODBC tracing enabled on my development machine using the
"default" tracing DLL.
I thought it was just our applications causing this, but I'm also seeing
this when using isqlw (SQL Query Analyzer).
Is it an issue? The app. seems to have no issues. I know it is indicating
that the memory location is invalid. Why?
I would like to know what the cause is, what other tools are available to
track this down, in the event it is an issue. It doesn't seem like a
"normal" occurrence.
From our app:
12345678.A24 N 95c-cdc EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS
)
SQLHENV 008F1540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER 0
12345678.A24 N 95c-cdc EXIT SQLSetConnectAttr with return code 0
(SQL_SUCCESS)
SQLHDBC 008F15E8
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x0000003C (BADMEM)
SQLINTEGER 0
From ISQLW:
isqlw edc-9c4 EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS
)
SQLHENV 008D1540
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER -5
isqlw edc-9c4 EXIT SQLSetConnectAttrW with return code 0
(SQL_SUCCESS)
SQLHDBC 008D15E8
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x0000000F (BADMEM)
SQLINTEGER -5
isqlw edc-9c4 EXIT SQLSetStmtAttrW with return code 0
(SQL_SUCCESS)
SQLHSTMT 008D19B8
SQLINTEGER 3 <SQL_ATTR_MAX_LENGTH>
SQLPOINTER 0x0000FC00 (BADMEM)
SQLINTEGER -5
Thanks. JeffHello,
This behavior seems to be normal because some parameters are not used when
calling this method. Also, the SQL_SUCCESS indicate these functions work
fine. For example:
SQLSetConnectAttr Function
http://msdn.microsoft.com/library/d...-us/odbc/htm/od
bcsqlsetconnectattr.asp
ValuePtr
[Input]
Pointer to the value to be associated with Attribute. Depending on the
value of Attribute, ValuePtr will be a 32-bit unsigned integer value or
will point to a null-terminated character string. Note that if the
Attribute argument is a driver-specific value, the value in ValuePtr may be
a signed integer.
Sophie Guo
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
========================================
=============
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.
Monday, February 20, 2012
ODBC linked table support in SQL SERVER 2005
Hi,
We still have some legacy applications that use ODBC linked tables to access SQL SERVER 2000.
Questions: Will these legacy applications still function with SQL SERVER 2005 / SQL SERVER 2005 Express? In order to relink the tables within the Access front-end do we need to install the new SQL Native Client that contains the new ODBC driver for SQL SERVER 2005?
Any input would be appreciated.
ThanksThe existing SQL Server 2000 ODBC driver can be used with SQL Server 2005, there is no need to update existing clients just because you upgraded the server. In general you only have to upgrade to SQL Native Client when you change application code to take advantage of new features in SQL Server 2005.|||What version of the SQL Server 2000 ODBC Driver is supported for accessing SQL Server 2005 databases? Thanks.|||
2.5 and later are supported with SQL Server 2005.
In general, since MDAC is now part of Windows, if you're up to date on Windows service packs you should have no problems. For Windows 2000 and later this means you'll have 2.81 installed.
ODBC linked table support in SQL SERVER 2005
Hi,
We still have some legacy applications that use ODBC linked tables to access SQL SERVER 2000.
Questions: Will these legacy applications still function with SQL SERVER 2005 / SQL SERVER 2005 Express? In order to relink the tables within the Access front-end do we need to install the new SQL Native Client that contains the new ODBC driver for SQL SERVER 2005?
Any input would be appreciated.
ThanksThe existing SQL Server 2000 ODBC driver can be used with SQL Server 2005, there is no need to update existing clients just because you upgraded the server. In general you only have to upgrade to SQL Native Client when you change application code to take advantage of new features in SQL Server 2005.
|||What version of the SQL Server 2000 ODBC Driver is supported for accessing SQL Server 2005 databases? Thanks.|||
2.5 and later are supported with SQL Server 2005.
In general, since MDAC is now part of Windows, if you're up to date on Windows service packs you should have no problems. For Windows 2000 and later this means you'll have 2.81 installed.
Subscribe to:
Posts (Atom)