Transaction in Enterprise library - sql-server-2008

How to handle transaction within a scope using Enterprise library. I've 3 stored procedures, which I need to execute in a single scope. I dont want to use System.Transaction name space

You can call the BeginTransaction method on a connection object to get a DbTransaction object. Then use the Entlib Database object's overloads that take a DbTransaction. However, it's a giant pain to manage. You'll need to create and close least one connection manually rather than relying on Entlib to do the right thing, and you'll have to pass the DbTransaction object around to everything that needs it.
TransactionScope really is the right answer here. If you've got some blocking scenario that really prevents you from using it that isn't some brain-dead corporate policy, I'd love to know what it is.

Related

A callback for ActiveRecord database connections?

Is there any way to hook into ActiveRecord connection creation? I want to run some code whenever a connection has just been created.
I feel like it might be a way to set a MySQL variable on the connection, since "variables" in database.yml doesn't seem to work for me. (How to turn off MySQL strict mode in Rails)
The ConnectionAdapter defines two callbacks :checkout (connect) and :checkin (disconnect). You can use it for specific adapter as
ActiveRecord::ConnectionAdapters::MysqlAdapter.set_callback :checkout, :after do
raw_connection.set_your_variables ...
end
Or you can use ActiveRecord::Base.connection.class for whatever adapter is currently declared in database.yml
Also, if you need to configure your model after connection has been made and column information was retrieved, you can redefine load_schema! class method in model.
See: https://github.com/rails/rails/pull/31681#issuecomment-357113030
Just to add to the accepted solution, if you need to fire a database query from within the callback, you can do so in the following way:
ActiveRecord::ConnectionAdapters::AbstractAdapter.set_callback :checkout, :before, ->(conn) {
res = conn.execute('SELECT COUNT(*) from table_name')
puts "res is #{res.each { |tuple| puts tuple.inspect}}"
}
Note: since callback is defined on ActiveRecord::ConnectionAdapters::AbstractAdapter, this should be executed before checking out connection for ANY database type
As #Envek pointed out in comment to the accepted answer, you should not really use ActiveRecord models since you risk running into endless recursion. Also (also noted by #Envek) keep in mind that the callback will be fired on each connection checkout with pooled connections, not just once.
Finally, the chances are, you want to use this from Rails. If so, you can place this code in a file under config/initializers folder. Then it would be run on application startup. Useful for cases where you want to add logic to how database connection is established, especially if precise action depends on results of a specific query.

Passing DAO.Workspace as a parameter - Bad idea?

In David Fenton's answer to the question "MS Access (Jet) transactions, workspaces" he states:
I would also say, never pass the workspace -- only pass the objects you've created with the workspace.
Is passing the workspace a bad idea? If so, why?
Additional info:
My intent here is to execute INSERT/UPDATE/DELETE statements from within multiple Subs/Functions but wrap them all in a single transaction.
The base functionality is wrapped up in a class module. I want to be able to isolate multiple instances of the class module, which means I can't just assume my transactions are executing against the default workspace.

MySQL username variable carried over to another file

So I just set this up:
http://www.phpeasystep.com/phptu/6.html
It was fairly easy, now I have it redirecting to another page but how can I pull the successful username used?
I'm trying to build a basic chat program to learn with.
Getting this would solve how I will add the variable when a message is sent off to the mysql database and to verify it was sent by the right person.
I think you are looking for what we commonly call SESSION variables. This type of variable offers persistence over different pages. The api for handling sessions is nice and simple, and in my (personal opinion) session variables can be very handy, and dead simple to put in action.
Especially for tasks like the one you have at hand, keeping messages and usernames and such. You can even pass objects in sessions, if you want to get wild, just serialise and deserialise the data before and after saving it in a $_SESSION var.
Read up the session handling section in php, this should give you a hint on how to tackle your problem.
On a sidenote, though, there are other ways that don't need session variables, since you posted php code I assumed you wanted a php related answer.
Good-luck

Can I reuse the connection from DataContext in Linq to Sql?

DataContext has Connection property of type DbConnection and I was wondering if I could re-use it. I've tried to use it creating a command using CreateCommand and using a reader off of it but I've gotten errors saying there is a pending transaction or something similar.
Basically I'm trying to find out if there is a best practice or guidance on re-using that connection object.
The connection string itself doesn't really help since I can't create a new connection object with the abstract type and I don't want the code to know the specific provider type either.
One alternative approach I'm thinking of doing is having my DataContext derived type to have members that provide a factory method to create a new connection using the same connection information.
FYI, this inquiry stems from the need to invoke an ad-hoc stored procedure through DataContext, not the design-time ExecuteMethodCall variety. I didn't know about ExecuteQuery and for now that suffices. But for other situations where ExecuteQuery is inadequate, I'd need the low-level data access using connection/command etc.
Why not turn it around, and instead supply connections to the datacontext by using the constructor that takes a connection as a parameter? That way you can control when connections are created and disposed, opened and closed, and can reuse them for other purposes without having to worry about the internal behavior of the L2S datacontext...
I can't say definitely, but a connection is a connection. Until it's been closed (or returned to the connection pool), it should be viable to use, whether via LINQ or other means.

Access - Data Provider Not Initialised?

I have used Access 2003 to develop a frontend to a SQL Server database. Because the system was intended to use different Schemas to partition the table data, an Access Project did not work. So, instead, I am forced to take over the connection management for access - I maintain a global connection object, and assign recordsets to Forms rather than recordsources.
One issue this causes - any time someone tries to use built-in Access functionality that interacts with the recordset, the operation doesn't work, and a dialog box is displayed saying 'Data Provider could not be initialised'. I've done some research, and have been unable to find a relevant cause for this, but I suspect it's due to Access expecting a Form to have a proper recordsource property, and does not really work with assigned recordsets.
Anyone able to shed any more light on this one? Is there a way to use self-managed recordsets, AND make use of built-in functionality? Can anyone confirm this is an Access bug?
After some playing around, I found a partial solution. I was using Client-side cursors, but leaving the recordsets connected. By instead disconnecting the recordsets, the Data Provider messages went away. Of course, that introduced other issues, but that's another story...and of course, I still don't understand WHY doing this made a difference...anyone else?