Hi

I'm trying to use the IActionQuery and ExecuteActionQuery of the adapter. OK, I know that I have to setup an IDbCommand with the query to be executed.

My problem is, that the current connection of the adapter is not injected into the IActionQuery , i.e. the IDbCommand, and therefore the execution fails.

So, how do I get the CurrentConnection of the adapter?

Is this by design?

Thanx

Christoph

NS: using the latest version 2.0

Override in a derived class of DataAccessAdapter the method CreateNewPhysicalConnection. Call the base' method and you have your connection

Thanks,

I could do that.

But then I do not unterstand why you do open an connection before the execution of the query and close the connection afterwards. I mean you do not mention that I have to subclass the adapter in order to make this work. And it doesn't make sense (for me )

So I extend the DataAccessAdapter and will override the ExecuteActionQuery

Thank you

Christoph

I don't mention that as it's not a designed feature to have you build your own IActionQuery objects and execute them. Connection is opened before execution to wire a transaction if required.

Thank you.

I thought I could use that method to set up the database before use. I wanted to use it to send sql statements in order to create the database without fiddeling with the System.Data classes. Since the adapter already encapsulates the used database (Microsoft, Oracle, etc) I thought, wow, this is the place I could use without looking again what database I use

Best regards

Christoph

Hi Frans,

I just had to tackle that issue once more for one of our app, and I'm wondering if you'd consider moving on from that trick.

(Here's what we've had so far

' __LLBLGENPRO_USER_CODE_REGION_START CustomDataAccessAdapterCode

        Public ReadOnly Property ActiveConnection() As IDbConnection
            Get
                Return MyBase.GetActiveConnection()
            End Get
        End Property

        ' __LLBLGENPRO_USER_CODE_REGION_END

I understand that using a custom ActionQuery to execute custom sql is not designed behaviour, but in some cases I think it can be quite legitimate:

Here's our scenario: We're handling publishing upgrades for some of our customers, for which we only have access to the web interface. As the db evolves, we upload packages for the newly generated dll / some schema updating scripts, which is ok. Then a dedicated interface allows for selectively running the update scripts.

I thought that running the scripts in an ActionQuery is the proper way since I benefit from the common configuration (connection string, schema etc...) and I can use cross scripts transactions more easily.

Basically, I would think that there are such scripts / queries that you can't handle with the ORM logic, and that in those cases I'm better leveraging the common low level ADO.Net wrapper provided by an DataAccessAdapter, than reverting to pure ADO.Net. That said, I'd feel better not having to tweak the standard code to do so.

Cheers,

PS: Looking forward to the incoming beta

So, basicly what you're saying is that in DataAccessAdapterBase.ExecuteActionQuery, I should check if there's a connection on the query object, and if not, it should create a connection and insert it?

Here's a snipet of what we are doing with running the multiple scripts (using PostgreSql).

...
Dim adapter As New DataAccessAdapter()
                    adapter.StartTransaction(IsolationLevel.ReadCommitted, "Updating Scripts")
                    Try
                        For Each scriptSQLFile In scriptsListToExecute
                            sqlScript = System.IO.File.ReadAllText(scriptSQLFile)

                            queryCommand= New NpgsqlCommand(sqlScript , adapter.ActiveConnection)
                            Dim scriptQuery As New ActionQuery(queryCommand)
                            adapter.ExecuteActionQuery(scriptQuery)
                            ...
                        Next
                        adapter.Commit()
                    Catch ex As Exception
                           adapter.Rollback()
                          LogException(ex)
                          ...
                    End Try
...

So basically the only tweak I needed was that additional ActiveConnection property as you also suggested. There might be other means, I'm not much into it now, but anything that could allow this natively is welcome.

Cheers

I'll add this to the v2.5 code, it's a very small piece of code to add

Good news, thanks Frans

Added in next build.