My current project is to be submitted for certification against the Microsoft Partner Program Platform Test for ISV Solutions. The application test specificiation states:

Applications must not misuse these resources (heaps, page heaps, locks and handles) in any way that could ever have potential negative consequences.

Kernel handles, including handles to files, events, and so on [DATABASE CONNECTIONS] can be misused in the following ways: * Reusing a handle after being closed. * Using a handle for an operation taht requires another handle type (you cannot read from an event) * Using a random handle value *Using a null handle or a pseudo-handle - for example, values returned by GetCurrentProcerss() when it is not permitted

Well, since all I can do with LLBLGen is adapter.OpenConnection() and adapter.CloseConnection() I have no way of verifying that those connection resources are properly disposed of. What are your thoughts on this requirement?

The document also states:

Applications must support ADO, ADO.NET, OLE DB, ODBC, OR JDBC to connect to SQL Server.

I can't even remember the last time I directly used ADO.NET, as all of my projects over the past couple of years have used LLBLGen. I can't help but wonder if we're going to fail the test because of this. Thoughts?

You can call adapter.Dispose() which disposes the connection object, if present. That's the normal way of doing it, and should obey the rules.

Is calling adapter.Dispose() recommended? I never call Dispose() on anything. It's been awhile since I read the relevant material in Richter, MSDN, whatever. But I think I would go crazy trying to call Dispose() on every object that supports it.

JimFoye wrote:

Is calling adapter.Dispose() recommended? I never call Dispose() on anything. It's been awhile since I read the relevant material in Richter, MSDN, whatever. But I think I would go crazy trying to call Dispose() on every object that supports it.

Calling adapter.Dispose will release the contained db connection to the pool immediately, instead of waiting for GC to pick it up. It's recommended practice for those objects implementing IDisposable, which, by definition, contain unmanaged resources that need to be cleaned up.

Jeff...

I find it easier to wrap adapter in a using statement which has an implicit close and dispose.

That way I don't need to worry about the variable scope around the try-catch-finally block.

Using adapter as IDataAccessAdapter = Database.GetAdapter()
          adapter.SaveEntity(myCustomer, true)
End Using

jeffreygg wrote:

JimFoye wrote:

Is calling adapter.Dispose() recommended? I never call Dispose() on anything. It's been awhile since I read the relevant material in Richter, MSDN, whatever. But I think I would go crazy trying to call Dispose() on every object that supports it.

Calling adapter.Dispose will release the contained db connection to the pool immediately, instead of waiting for GC to pick it up. It's recommended practice for those objects implementing IDisposable, which, by definition, contain unmanaged resources that need to be cleaned up. Jeff...

No, this isn't true. Closing the connection (if you kept it open, adapter will close a connection by itself if it opened it itself) already releases the connection to the pool.

Dispose is required on firebird and oracle databases. For firebird to release server-side resources, on oracle to release oracle-client related resources.

Ok, though I think it's still good practice to do so anyway, and to assume that anything implementing IDisposable should have its .Dispose() method called directly.

If the connection was opened manually, Dispose() is still the safest way to blindly ensure the adapter cleans itself up in a deterministic manner, correct?

Jeff...

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=3023&HighLight=1

Otis wrote:

You can call adapter.Dispose() which disposes the connection object, if present. That's the normal way of doing it, and should obey the rules.

So I can replace all of my calls to adapter.CloseConnection with adapter.Dispose? I almost always use the adapter constructor that accepts a boolean value and open the connection immediately. Before I write another line of code, I write a line that closes the connection.

alexdresko wrote:

Otis wrote:

You can call adapter.Dispose() which disposes the connection object, if present. That's the normal way of doing it, and should obey the rules.

So I can replace all of my calls to adapter.CloseConnection with adapter.Dispose? I almost always use the adapter constructor that accepts a boolean value and open the connection immediately. Before I write another line of code, I write a line that closes the connection.

In general you don't have to open the connection manually so CloseConnection isn't required, IF you just want to make 1 call.

CloseConnection and OpenConnection can be handy in a sequence of calls on teh same adapter. In general call closeconnection if you have to (thus after an OpenConnection call) and THEN call dispose. Dispose is really for the last cleanup actions, so call closeconnection when you're done with the connection and call dispose when you're done with the adapter. If you're placing the adapter usage inside a using statement, you don't have to worry about dispose calls.

BTW, I hope you'll keep us updated on your results from the test as you go through the process. I hear it's a bear, and I'd enjoy hearing things from someone going through it.

Thanks.

Indeed, I am interested to hear about this too, as we have some plans to proceed with platform tests as well.

bump. Has anyone had any experiences with Platform tests and llblgen?