Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Major mixup in two ASP.NET transactions
Message
From
25/09/2006 12:16:01
 
 
To
25/09/2006 11:31:39
General information
Forum:
ASP.NET
Category:
Other
Environment versions
Environment:
VB 8.0
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01150471
Message ID:
01156949
Views:
66
Hi,

Storing connection strings at the global level and reading them once on startup shouldn't cause any problem. And you've confirmed that the connection is always scoped to the DataProvider class (and presumably the DataProvider class is instantiated on every hit ?).
That still leaves my second question unanswered:
Are there *any* references to connections held in, or referenced from, oApp?
(Including possible indirect ones via .DataProvider etc.
Regards,
Viv



>>I've just read through the thread to date. The problem does seem to be that you are somehow (*sometimes*) using a connection referenced at the global level (given that you have no shared properties).
>>
>>And if that is true then it is possible that Steven's suggestion as to the cause of the SQL errors is valid - if when you open a connection you then set the environment another hit that references the same connection might use it before that setup is complete.
>>
>>Are the connections always created by your oProcess object? Are there *any* references to connections held in or referenced from oApp?
>>
>>As a debug exercise you might add a GUID property to your connection class and log this before some of the offending error lines. This should enable you to check whether different hits were actually accessing the same connection and, if so, might also provide a clue as to where this was happening...?
>
>The connection strings are set in the framework application initialization sequence. So, I always refer them as:
>
>oApp.aConnection(1)
>
>for example.
>
>As I don't want to read my INI file at every hit, I read it at the application initialization time. Does this mean I will have to read the INI file at every hit just so to avoid this problems?
>
>But, this is only for the connection strings. The connection object itself is done when I create an instance of the data provider class. So, I really don't see how this could be a problem here. The top of my data class is as follow:
>
>
>Namespace Framework
>
>    Public Class Data
>
>        Public cSQL As String = ""
>        Public cConnectionString As String = ""
>        Public nCount As Integer = 0
>        Public nNoMember As Integer = 0
>
>        ' This is the primary key after an insert which is calculated from the auto incremental key
>        Public nPrimaryKey As Integer = 0
>
>        Public nSQLMode As Integer = 1
>        Public oApp As Framework.App
>        Public oDataSet As DataSet
>        Public oDataTable As DataTable
>        Public oDataView As DataView
>        Public oProcess As Framework.LXProcess
>
>        Private cSQLParse As String = ""
>        Private oCommand As IDbCommand = Nothing
>        Private oCommandText As New Collection
>        Private oConnection As IDbConnection = Nothing
>        Private oDataAdapter As IDbDataAdapter = Nothing
>        Private oDataParameter As IDbDataParameter = Nothing
>        Private oDataReader As IDataReader = Nothing
>        Private oParameters As New ArrayList
>        Private oParameters2 As New Collection
>
>
>The class contains a property oConnection. It is initialized at every method call. So, the connection object is only used every time a call is done to SQLExec(), SQLUpdate() or SQLInsert() for example.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform