I have recently moved some native Access tables to SQL Server 7. These tables are updated in code. When the update is done via a SQL statement, I get
"This record is being modified by another user. . . Save, Copy to Clipboard, Drop Changes"
When the record is being updated via DAO code, I get,
"ODBC Call Fail"
Both errors are most irritating and I desperately need to find a way around this. Any suggestions would be greatly appreciated.
CrystalHi there,
Maybe this information helps you on the way...
-- Microsoft Knowledge Base Article - 128809
-- Zoek in de Google nieuwsgroepen naar Onderwerp:
"auto_increment fields and #Deleted in MS Access?"
Nieuwsgroep:
-> mailing.database.myodbc
Greetz,
DePrins
:)
Showing posts with label fail. Show all posts
Showing posts with label fail. Show all posts
Monday, March 19, 2012
ODBC call fail/ Record Locked
I am in the process of moving native Access tables over to
SQL Server 7. These tables are updated through code.
Some are updated with SQL statements executed through a db
object and others are updated using DAO.
When I update using SQL, I get "This record is being
modified by another user. . . Save, Copy to Clipboard,
Drop Changes."
When I update using DAO, the code crashes on the .Update
command and says, "ODBC call fail."
I can update the tables manually without error.
Is there a way to fix this? What am I doing wrong in the
code?
Crystal
You should seriously consider getting rid of all DAO code that
performs DML against SQL Server tables. It's the slowest, buggiest,
and least-efficient way of performing any task. The reason is that you
are invoking an instance of the Jet engine on every call. The result
is that the call goes through Jet-ODBC-SQL Server. However, if you use
SQL statements in a pass-through query, the statement is passed
directly to SQL Server, where it is executed on the server. This
results in faster, more efficient transactions. Pass-through queries
also give you the capability of calling stored procedures, and can be
used as the basis of reports. If you must use recordsets for some
reason, use ADO, not DAO when going against SQL Server data.
-- Mary
Microsoft Access Developer's Guide to SQL Server
http://www.amazon.com/exec/obidos/ASIN/0672319446
On Mon, 3 May 2004 06:32:13 -0700, "Crystal"
<anonymous@.discussions.microsoft.com> wrote:
>I am in the process of moving native Access tables over to
>SQL Server 7. These tables are updated through code.
>Some are updated with SQL statements executed through a db
>object and others are updated using DAO.
>When I update using SQL, I get "This record is being
>modified by another user. . . Save, Copy to Clipboard,
>Drop Changes."
>When I update using DAO, the code crashes on the .Update
>command and says, "ODBC call fail."
>I can update the tables manually without error.
>Is there a way to fix this? What am I doing wrong in the
>code?
>Crystal
SQL Server 7. These tables are updated through code.
Some are updated with SQL statements executed through a db
object and others are updated using DAO.
When I update using SQL, I get "This record is being
modified by another user. . . Save, Copy to Clipboard,
Drop Changes."
When I update using DAO, the code crashes on the .Update
command and says, "ODBC call fail."
I can update the tables manually without error.
Is there a way to fix this? What am I doing wrong in the
code?
Crystal
You should seriously consider getting rid of all DAO code that
performs DML against SQL Server tables. It's the slowest, buggiest,
and least-efficient way of performing any task. The reason is that you
are invoking an instance of the Jet engine on every call. The result
is that the call goes through Jet-ODBC-SQL Server. However, if you use
SQL statements in a pass-through query, the statement is passed
directly to SQL Server, where it is executed on the server. This
results in faster, more efficient transactions. Pass-through queries
also give you the capability of calling stored procedures, and can be
used as the basis of reports. If you must use recordsets for some
reason, use ADO, not DAO when going against SQL Server data.
-- Mary
Microsoft Access Developer's Guide to SQL Server
http://www.amazon.com/exec/obidos/ASIN/0672319446
On Mon, 3 May 2004 06:32:13 -0700, "Crystal"
<anonymous@.discussions.microsoft.com> wrote:
>I am in the process of moving native Access tables over to
>SQL Server 7. These tables are updated through code.
>Some are updated with SQL statements executed through a db
>object and others are updated using DAO.
>When I update using SQL, I get "This record is being
>modified by another user. . . Save, Copy to Clipboard,
>Drop Changes."
>When I update using DAO, the code crashes on the .Update
>command and says, "ODBC call fail."
>I can update the tables manually without error.
>Is there a way to fix this? What am I doing wrong in the
>code?
>Crystal
ODBC call fail/ Record Locked
I am in the process of moving native Access tables over to
SQL Server 7. These tables are updated through code.
Some are updated with SQL statements executed through a db
object and others are updated using DAO.
When I update using SQL, I get "This record is being
modified by another user. . . Save, Copy to Clipboard,
Drop Changes."
When I update using DAO, the code crashes on the .Update
command and says, "ODBC call fail."
I can update the tables manually without error.
Is there a way to fix this? What am I doing wrong in the
code?
CrystalYou should seriously consider getting rid of all DAO code that
performs DML against SQL Server tables. It's the slowest, buggiest,
and least-efficient way of performing any task. The reason is that you
are invoking an instance of the Jet engine on every call. The result
is that the call goes through Jet-ODBC-SQL Server. However, if you use
SQL statements in a pass-through query, the statement is passed
directly to SQL Server, where it is executed on the server. This
results in faster, more efficient transactions. Pass-through queries
also give you the capability of calling stored procedures, and can be
used as the basis of reports. If you must use recordsets for some
reason, use ADO, not DAO when going against SQL Server data.
-- Mary
Microsoft Access Developer's Guide to SQL Server
http://www.amazon.com/exec/obidos/ASIN/0672319446
On Mon, 3 May 2004 06:32:13 -0700, "Crystal"
<anonymous@.discussions.microsoft.com> wrote:
>I am in the process of moving native Access tables over to
>SQL Server 7. These tables are updated through code.
>Some are updated with SQL statements executed through a db
>object and others are updated using DAO.
>When I update using SQL, I get "This record is being
>modified by another user. . . Save, Copy to Clipboard,
>Drop Changes."
>When I update using DAO, the code crashes on the .Update
>command and says, "ODBC call fail."
>I can update the tables manually without error.
>Is there a way to fix this? What am I doing wrong in the
>code?
>Crystal
SQL Server 7. These tables are updated through code.
Some are updated with SQL statements executed through a db
object and others are updated using DAO.
When I update using SQL, I get "This record is being
modified by another user. . . Save, Copy to Clipboard,
Drop Changes."
When I update using DAO, the code crashes on the .Update
command and says, "ODBC call fail."
I can update the tables manually without error.
Is there a way to fix this? What am I doing wrong in the
code?
CrystalYou should seriously consider getting rid of all DAO code that
performs DML against SQL Server tables. It's the slowest, buggiest,
and least-efficient way of performing any task. The reason is that you
are invoking an instance of the Jet engine on every call. The result
is that the call goes through Jet-ODBC-SQL Server. However, if you use
SQL statements in a pass-through query, the statement is passed
directly to SQL Server, where it is executed on the server. This
results in faster, more efficient transactions. Pass-through queries
also give you the capability of calling stored procedures, and can be
used as the basis of reports. If you must use recordsets for some
reason, use ADO, not DAO when going against SQL Server data.
-- Mary
Microsoft Access Developer's Guide to SQL Server
http://www.amazon.com/exec/obidos/ASIN/0672319446
On Mon, 3 May 2004 06:32:13 -0700, "Crystal"
<anonymous@.discussions.microsoft.com> wrote:
>I am in the process of moving native Access tables over to
>SQL Server 7. These tables are updated through code.
>Some are updated with SQL statements executed through a db
>object and others are updated using DAO.
>When I update using SQL, I get "This record is being
>modified by another user. . . Save, Copy to Clipboard,
>Drop Changes."
>When I update using DAO, the code crashes on the .Update
>command and says, "ODBC call fail."
>I can update the tables manually without error.
>Is there a way to fix this? What am I doing wrong in the
>code?
>Crystal
ODBC Call fail - Strange behaviour
Hi.
I just installed Sql server (in fact MSDE) and exported my Access 2002
projet to this database instance.
I then linked my Sql server tables within my access project.
I get a strange behaviour for some queries. I receive the message 'ODBC -
Call fail'. It seems to be a timeout pb.
The query involves two tables.
I checked my query. Everithing is ok.
I checked the first table. I can read data and filter it.
I checked the second table. I can read data, but if I want to filter any
column, I get an ODBC call fail. The table contains only 802 records.
Any idea ?
Configuration :
MSDE Rel A on XP home SP1.
Access 2002 client, MDAC 2.8, on XP Pro.
Check your data on the SQL server. You may have some data that is null and
the SQL server table def is not allowing nulls? Just a thought. Usually
these errors are caught during the import process...
I would start by creating a brand new query and only add one column at a
time. See if you can then sort on that column. Carry on like this - adding
new columns each time until the error happens. Then check that columns data
on the SQL server so see if there happens to be null values present...
"Alain" <alain.roghi_nospam@.laposte.net> wrote in message
news:uU5H9BEmEHA.2180@.TK2MSFTNGP12.phx.gbl...
> Hi.
> I just installed Sql server (in fact MSDE) and exported my Access 2002
> projet to this database instance.
> I then linked my Sql server tables within my access project.
> I get a strange behaviour for some queries. I receive the message 'ODBC -
> Call fail'. It seems to be a timeout pb.
> The query involves two tables.
> I checked my query. Everithing is ok.
> I checked the first table. I can read data and filter it.
> I checked the second table. I can read data, but if I want to filter any
> column, I get an ODBC call fail. The table contains only 802 records.
> Any idea ?
> Configuration :
> MSDE Rel A on XP home SP1.
> Access 2002 client, MDAC 2.8, on XP Pro.
>
I just installed Sql server (in fact MSDE) and exported my Access 2002
projet to this database instance.
I then linked my Sql server tables within my access project.
I get a strange behaviour for some queries. I receive the message 'ODBC -
Call fail'. It seems to be a timeout pb.
The query involves two tables.
I checked my query. Everithing is ok.
I checked the first table. I can read data and filter it.
I checked the second table. I can read data, but if I want to filter any
column, I get an ODBC call fail. The table contains only 802 records.
Any idea ?
Configuration :
MSDE Rel A on XP home SP1.
Access 2002 client, MDAC 2.8, on XP Pro.
Check your data on the SQL server. You may have some data that is null and
the SQL server table def is not allowing nulls? Just a thought. Usually
these errors are caught during the import process...
I would start by creating a brand new query and only add one column at a
time. See if you can then sort on that column. Carry on like this - adding
new columns each time until the error happens. Then check that columns data
on the SQL server so see if there happens to be null values present...
"Alain" <alain.roghi_nospam@.laposte.net> wrote in message
news:uU5H9BEmEHA.2180@.TK2MSFTNGP12.phx.gbl...
> Hi.
> I just installed Sql server (in fact MSDE) and exported my Access 2002
> projet to this database instance.
> I then linked my Sql server tables within my access project.
> I get a strange behaviour for some queries. I receive the message 'ODBC -
> Call fail'. It seems to be a timeout pb.
> The query involves two tables.
> I checked my query. Everithing is ok.
> I checked the first table. I can read data and filter it.
> I checked the second table. I can read data, but if I want to filter any
> column, I get an ODBC call fail. The table contains only 802 records.
> Any idea ?
> Configuration :
> MSDE Rel A on XP home SP1.
> Access 2002 client, MDAC 2.8, on XP Pro.
>
Friday, March 9, 2012
Occasional Error When Executing CLR Stored Procedure
This CLR stored procedure executes without fail 99% of the time. However, occasionally it will fail with the following error:
A .NET Framework error occurred during execution of user-defined routine or aggregate "Run_SRS_Report": System.Exception: Attempt to perform native server operation (AllocateNativeRequest) outside of its valid scope.
Below is the section of code that fails:
<code>
Private Shared Sub GetReportParameters()
Dim drReportParameters As SqlDataReader
Try
' set the parameters for the command request.
_SQLCommandRequest = _SQLConnection.CreateCommand()
_SQLCommandRequest.CommandText = _spReportParms
_SQLCommandRequest.CommandType = CommandType.StoredProcedure
' get the information for the data reader request.
drReportParameters = _SQLCommandRequest.ExecuteReader
' make sure that we have something first.
If Not drReportParameters Is Nothing Then
' find out if we have any rows returned.
If drReportParameters.HasRows Then
' read each of the rows looking for the respective value.
While drReportParameters.Read
' make sure that we can get the appropriate code id.
If (Not IsDBNull(drReportParameters.Item("Code_ID"))) AndAlso (Not IsDBNull(drReportParameters.Item("Display_Text"))) Then
' set the parameters for each of the following internal variables.
Select Case drReportParameters.Item("Code_ID").ToString
Case Is = "PDFP Path"
_FileLocationPDFP = drReportParameters.Item("Display_Text").ToString
Case Is = "PDF Temp Path"
_FileLocationPDFTemp = drReportParameters.Item("Display_Text").ToString
Case Is = "LogFile Path"
'''_SqlPipe.Send("Path from sys codes: " & drReportParameters.Item("Display_Text").ToString)
_FileLocationLogFile = Path.Combine(drReportParameters.Item("Display_Text").ToString, "SRSReportLog_" & Now.ToString("HHmmss") & ".txt")
Case Is = "LogFile Flag"
_swLogFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Is = "Delete PDF"
_DeletePDFFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Is = "PrintTool"
_PrintTool = drReportParameters.Item("Display_Text").ToString
Case Is = "BPP Path"
_BppPath = drReportParameters.Item("CharVar1").ToString
Case Is = "SendToPrinter"
_SendToPrinterFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Else
' ignore it.
End Select
End If
End While
End If
End If
Catch ex As Exception
' throw a new exception to trip up the PrintReport() function.
Throw New Exception(ex.Message)
Finally
' make sure that we close out the datareader, regardless.
If Not drReportParameters Is Nothing Then
If Not drReportParameters.IsClosed Then drReportParameters.Close()
End If
End Try
End Sub
</code>
Any ideas why this would fail only occasionally (maybe 1% of the time it's executed)?
_SQLCommandRequest is a shared (that is, static) variable, right? You are seeing this error because your proceduce is being executed on multiple threads at the same time, and multiple threads are not allowed to use the same SqlConnection at the same time. (The error message is fixed in the next version of SQL Server to be more clear what the problem is).It looks like you frequently use static variables within your SP, so even if you fix this problem by using a local, non-shared SqlCommand object, you will run into other problems due to multiple threads accessing the same shared state.
Steven
|||
Understood. Thanks for the explanation.
So all I have to do is make everything local, non-shared then right?
Except for the main sub procedure declaration below which has to remain shared right?:
<Microsoft.SqlServer.Server.SqlProcedure()> _
Public Shared Sub Run_SRS_Report(ByVal ip_URL As String _
Am I on the right track?
|||Yes, everything should be a local or class instance field, unless it is a constant, readonly value. Ideally, you should try to deploy the assembly under SAFE or EXTERNAL_ACCESS permission set, which disallows the use of static variables to prevent this type of problem.
|||
Thanks Steven. I've changed everything up so there are no static variables and re-deployed. Hopefully that will fix the problem. If not I'll post again.
Occasional Error When Executing CLR Stored Procedure
This CLR stored procedure executes without fail 99% of the time. However, occasionally it will fail with the following error:
A .NET Framework error occurred during execution of user-defined routine or aggregate "Run_SRS_Report": System.Exception: Attempt to perform native server operation (AllocateNativeRequest) outside of its valid scope.
Below is the section of code that fails:
<code>
Private Shared Sub GetReportParameters()
Dim drReportParameters As SqlDataReader
Try
' set the parameters for the command request.
_SQLCommandRequest = _SQLConnection.CreateCommand()
_SQLCommandRequest.CommandText = _spReportParms
_SQLCommandRequest.CommandType = CommandType.StoredProcedure
' get the information for the data reader request.
drReportParameters = _SQLCommandRequest.ExecuteReader
' make sure that we have something first.
If Not drReportParameters Is Nothing Then
' find out if we have any rows returned.
If drReportParameters.HasRows Then
' read each of the rows looking for the respective value.
While drReportParameters.Read
' make sure that we can get the appropriate code id.
If (Not IsDBNull(drReportParameters.Item("Code_ID"))) AndAlso (Not IsDBNull(drReportParameters.Item("Display_Text"))) Then
' set the parameters for each of the following internal variables.
Select Case drReportParameters.Item("Code_ID").ToString
Case Is = "PDFP Path"
_FileLocationPDFP = drReportParameters.Item("Display_Text").ToString
Case Is = "PDF Temp Path"
_FileLocationPDFTemp = drReportParameters.Item("Display_Text").ToString
Case Is = "LogFile Path"
'''_SqlPipe.Send("Path from sys codes: " & drReportParameters.Item("Display_Text").ToString)
_FileLocationLogFile = Path.Combine(drReportParameters.Item("Display_Text").ToString, "SRSReportLog_" & Now.ToString("HHmmss") & ".txt")
Case Is = "LogFile Flag"
_swLogFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Is = "Delete PDF"
_DeletePDFFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Is = "PrintTool"
_PrintTool = drReportParameters.Item("Display_Text").ToString
Case Is = "BPP Path"
_BppPath = drReportParameters.Item("CharVar1").ToString
Case Is = "SendToPrinter"
_SendToPrinterFlag = IIf(drReportParameters.Item("Display_Text").ToString = "False", False, True)
Case Else
' ignore it.
End Select
End If
End While
End If
End If
Catch ex As Exception
' throw a new exception to trip up the PrintReport() function.
Throw New Exception(ex.Message)
Finally
' make sure that we close out the datareader, regardless.
If Not drReportParameters Is Nothing Then
If Not drReportParameters.IsClosed Then drReportParameters.Close()
End If
End Try
End Sub
</code>
Any ideas why this would fail only occasionally (maybe 1% of the time it's executed)?
_SQLCommandRequest is a shared (that is, static) variable, right? You are seeing this error because your proceduce is being executed on multiple threads at the same time, and multiple threads are not allowed to use the same SqlConnection at the same time. (The error message is fixed in the next version of SQL Server to be more clear what the problem is).It looks like you frequently use static variables within your SP, so even if you fix this problem by using a local, non-shared SqlCommand object, you will run into other problems due to multiple threads accessing the same shared state.
Steven
|||
Understood. Thanks for the explanation.
So all I have to do is make everything local, non-shared then right?
Except for the main sub procedure declaration below which has to remain shared right?:
<Microsoft.SqlServer.Server.SqlProcedure()> _
Public Shared Sub Run_SRS_Report(ByVal ip_URL As String _
Am I on the right track?
|||Yes, everything should be a local or class instance field, unless it is a constant, readonly value. Ideally, you should try to deploy the assembly under SAFE or EXTERNAL_ACCESS permission set, which disallows the use of static variables to prevent this type of problem.
|||
Thanks Steven. I've changed everything up so there are no static variables and re-deployed. Hopefully that will fix the problem. If not I'll post again.
Subscribe to:
Posts (Atom)