Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Scoping of class property
Message
De
19/12/2005 21:23:45
 
 
À
19/12/2005 14:20:24
Information générale
Forum:
ASP.NET
Catégorie:
Code, syntaxe and commandes
Divers
Thread ID:
01079106
Message ID:
01079399
Vues:
62
Ok, I think I have resolved it. Basically, is in related to my quest for optimization. It is what you get penalized for, after searching for more than one day to resolve that issue, when you build Web applications. For such applications, as it was the case in VFP, I am opening up all data sources so this saves a lot of time for each Web server process. So, for this .NET framework, one I started to work on since about a year, when I wanted to optimize in that direction, I decided to create all data source connections when the application loads. I thought I would them be able to pass them as a parameter by the use of the data provider object.

This works really well for desktop and ASP.NET applications. But, for Web Services, when simultaneous hits are being received, it caused me all kind of problems. Basically, as the same connection object was passed to the data provider object, when simultaneous hits were received, one session was overwriting the other and so on.

So, to resolve the issue, I am passing the connection string instead and create the connection object inside the SQLExec() method. By doing that, the entire data objects are encapsulated within that method only and no mix up of environments can happen. Here is the new code of the Framework.Data() class:
Imports System.Data.OleDb

Public Class Data

    Public oDataAdapter As OleDbDataAdapter
    Public oDataSet As DataSet
    Public oDataView As DataView
    Public cSQL As String
    Public cConnectionString As String
    Public oConnection As OleDbConnection
    Public nCount As Integer

    ' SQL exec
    ' expC1 SQL command
    ' expO1 Connection
    Public Function SQLExec(ByVal tcSQL As String, ByVal tcConnection As String) As Boolean
        Dim llSuccess As Boolean
        Dim loConnection As OleDbConnection
        Dim lnStatus As Integer
        llSuccess = False
        cSQL = tcSQL
        cConnectionString = tcConnection
        Try
            lnStatus = 1
            loConnection = New OleDbConnection(tcConnection)
            lnStatus = 2
            loConnection.Open()
            lnStatus = 3
            oDataAdapter = New OleDbDataAdapter
            lnStatus = 4
            oDataAdapter.SelectCommand = New OleDbCommand(tcSQL, loConnection)
            lnStatus = 5
            oDataSet = New DataSet
            lnStatus = 6
            oDataAdapter.Fill(oDataSet, "Temp")
            lnStatus = 7

            ' Record count
            nCount = oDataSet.Tables("Temp").Rows.Count

            ' If we have at least one record
            If nCount > 0 Then
                oDataView = New DataView
                oDataView = oDataSet.Tables("Temp").DefaultView
            End If

            loConnection.Close()
            llSuccess = True
        Catch loError As Exception
            App.ErrorSetup(loError, "Framework.Data.SQLExec()", lnStatus.ToString)
        End Try
        Return llSuccess
    End Function

End Class
It is when I decided to add a status after each line that I was able to locate the exact place where all those errors were coming from. It was in the line where I fill the dataset. After about two hours, this is when I realized that the connection object should be created in here for the encapsulation purpose.

I don't know if this would be as fast as before. Because, for every data request, I need to create a connection.
Michel Fournier
Level Extreme Inc.
Designer, architect, owner of the Level Extreme Platform
Subscribe to the site at https://www.levelextreme.com/Home/DataEntry?Activator=55&NoStore=303
Subscription benefits https://www.levelextreme.com/Home/ViewPage?Activator=7&ID=52
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform