Develop Reference

ServiceStack OrmLite - Capture Sql InfoMessage event from stored procedure

Asked this question a few days ago but maybe wasn't too specific.
Basically, I'm writing a console app that accepts a list of stored procedure names and arbitrarily executes them. The app is supposed to log to Slack, etc. on the progress of these sprocs, as well as do some other stuff later.
The 'other stuff' I mentioned interacts with known database models, and since we have a library of ServiceStack/OrmLite types build up, I am using OrmLite to interact with the database later.
So, since I have OrmLite included and configured in the project, I'm just using the OrmLite IDbConnection to execute the stored procedures, even if it's just by name. The sprocs simply move data to another database, one that the app doesn't need to interact with -- so I'm not SELECTing any data into the app with the sprocs and there's no POCO representation of what's moved.
However, the sprocs spit out a number of informational PRINT statements that I want to capture and log to our team in a formatted manner via Slack. Enabling full-on debug logging spits out a little too much information for this purpose.
Is there any way I can configure the Ormlite SqlServerDialect.Provider, the IDataReader, etc. to basically capture the SqlConnection.InfoMessage
event (or to provide it with a connection already prepped with a SqlInfoMessageEventHandler)?

The logging strategy approach for doing this is to configure a filter in your logging provider to only log the messages you're interested in.
OrmLite's SQL debug logging messages containing the SQL and DB Params are logged under the ServiceStack.OrmLite.OrmLiteResultsFilterExtensions Type.
To make this scenario easier I've just added new OrmLiteConfig.BeforeExecFilter and OrmLiteConfig.AfterExecFilter which you can use to execute custom logic before and after a DB Command is executed, e.g:
OrmLiteConfig.BeforeExecFilter = dbCmd => Console.WriteLine(dbCmd.GetDebugString());
This change is available from v5.0.3 that's now available on MyGet.

Update:
Looking through the ServiceStack.OrmLite source, it looks like IDbConnection can be cast to SqlConnection using (SqlConnection)IDbConnection.ToDbConnetion().
Wrapping this up in an OrmLiteExecFilter to be called on every statement, casting the IDbConnection and creating the DbCommand with the cast connection worked for me:
public class LogInfoMessageFilter : OrmLiteExecFilter
{
ILog SlackLog = LogManager.GetLogger("SlackLogger");
public override T Exec<T>(IDbConnection dbConn, Func<IDbCommand, T> filter)
{
var holdProvider = OrmLiteConfig.DialectProvider;
// casting, skipping type checks for brevity
var sqlConn = (SqlConnection)dbConn.ToDbConnection();
// add the event
sqlConn.InfoMessage += _HandleInfoMessage;
var dbCmd = CreateCommand(sqlConn);
try
{
return filter(dbCmd);
}
finally
{
DisposeCommand(dbCmd, sqlConn);
OrmLiteConfig.DialectProvider = holdProvider;
}
}
private void _HandleInfoMessage(object sender, SqlInfoMessageEventArgs args)
{
SlackLog.Info($"what does the sproc say? {args.Message}");
}
}
// before opening the connection:
OrmLiteConfig.ExecFilter = new LogInfoMessageFilter();
However, now that #mythz has replied with an 'official' way to do this, I'll go about refactoring. Just thought I'd plop this here in case it suits anyone's use case.

Is it possible to connect to SQL Server without specifying a database?

I'm trying to write some unit tests for my code that connect to SQL Server for persistence, but I would like to be able to run my unit tests by just pointing it at a SQL Server instance, and let the tests create their own database to run tests in, so after each test it can just drop the database and then on setup before the next test recreate it, so I know there is no legacy data or structures left over from a previous test effecting the next test.

In brief: no, you cannot do that. You might be able to leave out the database from the connection string, but in that case, that connection will be made to the configured default database of the login that's connecting to SQL Server (and that default database must exist at the time the connection is made)
If you want to have this scenario, you need to
first connect to your instance and database master and create your new testdb (or whatever it's called)
disconnect
in your tests, connect to the instance and the testdb database
Better yet: use a mocking framework of some sort so you don't even need an actual database in your testing scenario!

I use the following class to facilitate the OP's scenario:
public class MsSqlDatabaseCreator
{
public void Create(string connectionstring)
{
if (DatabaseExists(connectionstring))
{
DropDatabase(connectionstring);
}
CreateDatabase(connectionstring);
}
private static void CreateDatabase(string connectionString)
{
var sqlConnectionStringBuilder = new SqlConnectionStringBuilder(connectionString);
var databaseName = sqlConnectionStringBuilder.InitialCatalog;
sqlConnectionStringBuilder.InitialCatalog = "master";
using (var sqlConnection = new SqlConnection(sqlConnectionStringBuilder.ConnectionString))
{
sqlConnection.Open();
using (var sqlCommand = sqlConnection.CreateCommand())
{
sqlCommand.CommandText = $"CREATE DATABASE {databaseName}";
sqlCommand.ExecuteNonQuery();
}
}
}
private static bool DatabaseExists(string connectionString)
{
var sqlConnectionStringBuilder = new SqlConnectionStringBuilder(connectionString);
var databaseName = sqlConnectionStringBuilder.InitialCatalog;
sqlConnectionStringBuilder.InitialCatalog = "master";
using (var sqlConnection = new SqlConnection(sqlConnectionStringBuilder.ConnectionString))
{
sqlConnection.Open();
using (var command = sqlConnection.CreateCommand())
{
command.CommandText = $"SELECT db_id('{databaseName}')";
return command.ExecuteScalar() != DBNull.Value;
}
}
}
private static void DropDatabase(string connectionString)
{
var sqlConnectionStringBuilder = new SqlConnectionStringBuilder(connectionString);
var databaseName = sqlConnectionStringBuilder.InitialCatalog;
sqlConnectionStringBuilder.InitialCatalog = "master";
using (var sqlConnection = new SqlConnection(sqlConnectionStringBuilder.ConnectionString))
{
sqlConnection.Open();
using (var sqlCommand = sqlConnection.CreateCommand())
{
sqlCommand.CommandText = $#"
ALTER DATABASE {databaseName} SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [{databaseName}]
";
sqlCommand.ExecuteNonQuery();
}
}
}
}
The important part is the switching of the database name (initial catalog) to master. This way you can have just one connectionstring.

What you want to accomplish is possible using a mocking framework, in which case you don't even have to "connect to a database", you simply mock the return values that the database should return in order for you to test your "db handler" implementation.
There are several to choose from when it comes to C#, I can recommend Rhino Mocks and Moq to name two. Here's a question detailing a bit more; https://stackoverflow.com/questions/37359/what-c-sharp-mocking-framework-to-use

Why not have the same named database dedicated for tests? and drop-create it every time. This way you won't need to mess about with connection strings - it is always the same.
And yet, there is a better solution: within all your tests, start transaction, do your test, where your data is messed up. Once you verified (or failed) the test, unroll the transaction. This way you don't need to drop-create your tests for every test, because the data is never changed.
But you'll need to make sure schema in test-database is always up to date. So you'll need to drop-create test database whenever your schema is changed.
I've blogged about database tests and how we deal with Entity Framework migrations. This might not be completely applicable to your situation, but might help with ideas.
Regarding using mocks in your tests - yes this is absolutely valid suggestion and should be followed most of the time. Unless you are trying to test the database layer. In that case no mocks will save you, and you just have to go to DB. Many times over I have tried to mock DbContext in EF, but never managed to simulate realistic DB behavior. So going to DB was easier for me, rather than simulating DB-mock.

I'd use SQL Server Management Objects for the task. It's Server and Database APIs doesn't necessarily need a connection string but I think you might still need to specify a database. You can use master for that. (Check jeroenh's answer about creating object using SMO API as well)
By the way, if you are using .Net 4.0.2 and up you can use LocalDB as well, which is even better.
Edit: Note that actually LocalDB is an SQL Server 2012 feature however you still need .Net Framework > 4.0.2 to be able to use it.

Error passing existing connections to DbContext constructor when using Database-First

I'm trying to create a class to perform work on the database and have the need (or preference) to use a combination of DbContext and good old fashioned ADO. Why, well EF is great for simplifying a great deal of code but ADO still has many uses for more complex methods that EF cannot yet handle.
This link on MSDN states that I can pass an existing SqlConnection to my context as follows:
using (var conn = new SqlConnection("..."))
{
conn.Open();
using (var context = new SampleContext(conn, contextOwnsConnection: false))
{
// Do Something
}
}
Now I'm using Database-First so this constructor doesn't appear as standard. I therefore created a new Partial Class file and created the appropriate constructor as follows:
public partial class MyEntities : DbContext
{
public MyEntities(System.Data.Common.DbConnection conn, bool contextOwnsConnection = false)
: base(existingConnection: conn, contextOwnsConnection: contextOwnsConnection)
{
}
}
However, when I run the code the moment it hits a call to the new DbContext constructor, I get the following UnintentionalCodeFirstException() error thrown by OnModelCreating in my EDMX file:
"Code generated using the T4 templates for Database First and Model First development may not work correctly if used in Code First mode. To continue using Database First or Model First ensure that the Entity Framework connection string is specified in the config file of executing application. To use these classes, that were generated from Database First or Model First, with Code First add any additional configuration using attributes or the DbModelBuilder API and then remove the code that throws this exception."
Am I missing something obvious here, or can it just not be done with Database-First?
Clearly, I could just use two connections, one for my SqlConnection object, and another for my DbContext object but if I can, naturally I'd prefer to use a single connection if possible.
Any and all help greatly appreciated. For full disclosure, I'm using SQL-Server 2012, .NET 4.5.1, C# and EF6.0.2.

Connection strings used by the designer are not regular connection strings. Rather they are EntityConnection strings. The difference is that entity connection strings contain additional information about where to find metadata describing the model which is in form of the edmx at design time - read more here. Code First uses just regular connection strings since it builds the model on the fly based on the code. So, the UnintentionalCodeFirstException is preventing the user from using CodeFirst functionality with edmx models because the model is specified in the edmx and not in the code and if it was allowed you would effectively end up using two different models (one from edmx and one built from the code) which very likely won't be in sync which would result in weird behavior or even could lead to data corruption and crashes/exceptions.
Since the EntityConnection is derived from DbConnection and just wraps regular connection you can use it in places where you would use the provider connection. Alternatively you can access the wrapped provider connection using the StoreConnection provider on the EntityConnection.

I know this is an old thread, but later versions of Entity Framework actually can handle a shared connection, so I offer this as an alternative answer.
You can initialize an instance of the entity container with a shared connection. Use the EntityConnection(MetadataWorkspace workspace, DbConnection connection, bool entityConnectionOwnsStoreConnection) overload and specify false for the entityConnectionOwnsStoreConnection parameter. Then pass it into your context constructor as the existing connection. The EntityConnection will then prevent the connection from being automatically closed and disposed with the context.
Example:
using (var conn = new SqlConnection("..."))
{
conn.Open();
// Execute some ADO queries.
var md = new MetadataWorkspace(new[]{"res://*/SampleModel.csdl","res://*/SampleModel.ssdl","res://*/SampleModel.msl"}, new[]{System.Reflection.Assembly.GetExecutingAssembly()});
// Create the EntityConnection so the existing connection is not disposed.
var ec = new EntityConnection(md, conn, false);
using (var context = new SampleContext(conn, contextOwnsConnection: false))
{
// Do something using the entity context.
}
// Entity context is disposed but connection remains open.
// Do more ADO stuff.
}
Yes, it was a pain to figure out this stuff by examining System.Data and Entity Framework source code.
This pattern may be used within a TransactionScope to prevent escalation to a distributed transaction by virtue of using the same database connection.

Mono can't open sqlite database

I'm attempting to do a very basic connection to a sqlite v3 database and I'm using monodevelop 3.0 and Mono 2.10 and am unable to get connected to the database. I can make the app create the database, but then it immediately fails attempting to connect to it. Any suggestions? I had started with a different database, but then decided to have my app attempt to create a database empty and then connect to it. This still seems to fail.
SqliteConnection.CreateFile("db\\DataWorksProg.s3db");
SqliteConnection conn = new SqliteConnection("Data Source=file:db\\DataWorksProg.s3db");
conn.Open();
This small piece of code fails with an error about not being able to open the database file.
Mono.Data.Sqlite.SqliteException: Unable to open the database file
Permissions look OK and I have the Sqlite3.dll in the project, and it seems to be working OK. Have I missed anything obvious? I'm pretty good on the Visual Studio side, but still fairly fresh working in a Mono/Monodevelop environment.

What platform?
I don't believe you need to create a file. If it's not found, iirc, it'll make the database file.
Fwiw, on a Mac, I'm doing (note URI to a pretty standard path; I haven't used Data Source)...
using System;
using System.Data;
using Mono.Data.Sqlite;
namespace test
{
class MainClass
{
public static void Main (string[] args)
{
IDbConnection conTemp = null;
IDbCommand cmdTemp = null;
conTemp = (IDbConnection)new SqliteConnection ("URI=file:/Users/userName/mnmh.db");
conTemp.Open ();
cmdTemp = conTemp.CreateCommand ();
cmdTemp.CommandText = "SELECT * FROM employee";
IDataReader drTemp = cmdTemp.ExecuteReader ();
while (drTemp.Read()) {
Console.WriteLine (drTemp.GetString (0));
}
}
}
}
etc etc
Check the obvious -- you've referenced all the stuff you're using, etc.

Figured out my problem here. Apparently instead of using
"Data Source=file:db\\DataWorksProg.s3db"
I should have been using
"URI=file:db\\DataWorksProg.s3db"
Switched to the URI and it works as expected. I had thought from reading the docs that under the 2.0 profile, the DataSource part was needed instead of the URI, but I got the results I'm looking for.

Beginner requests Help with Mysql and C#

I'm trying to build a program that uses a C# to work with a MySQL DB. I get the C# syntax, and can write the language, but I don't have much experience with the libraries, and I feel a bit lost.
Could someone post examples of how a program would be built (in technical terms, syntax would be nice, but pseudo code is fine, too)?
I understand the theory of how it works, but need a hands on approach to it.
Thank you.
EDIT
I forgot to add that I want to learn how to do it with the .NET v.2.0 framework / VS2005 / MySQL v5.0 combination.
EDIT # 2
2.0 .NET will only be supported. =)

Here is tutorial for Entity Framework + MySQL.
There are lots of other ways to operate with DB, depending on what you need:
If you need execute raw sql queries against DB - use OdbcConnection + OdbcCommand
Need to manipulate items in DB as objects - use ORM (EntityFramework, NHibernate, Linq2Sql)
Like old-style DB interop? - DataSets is your choice.
I really like EF. Easy thing to start with.
PS: And before mixing UI and DB-interop, please read about Separation of concerns. MVC is interesting to read about too. About "libraries": create another project in your solution and add DB-interop logics there. Don't mix it in one assembly, because when your project becomes bigger than "Hello DataBase!" application it will create a big mess in code and logics, really.
UPDATE:
Using VS2005 and .net 2.0 is mysterious idea, really. Lots of tools and assemblies where made since 2.0 release. Linq, Orm-s, etc. Live without them is hard and all the benefits of C# are lost. I highly recommend to use latest techniques, if there is no strict reasons to use 2.0.
If using SqlServer - ObdcCommand and OdbcConnection can be replaced to SqlCommand and SqlConnection. (thanks #Abe Miessler comment)

Here is an example swiped from MSDN:
public void InsertRow(string connectionString, string insertSQL)
{
using (OdbcConnection connection =
new OdbcConnection(connectionString))
{
// The insertSQL string contains a SQL statement that
// inserts a new row in the source table.
OdbcCommand command = new OdbcCommand(insertSQL, connection);
// Open the connection and execute the insert command.
try
{
connection.Open();
command.ExecuteNonQuery();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
// The connection is automatically closed when the
// code exits the using block.
}
}
If you want to read records in a DB, look at this example:
public static void ReadData(string connectionString)
{
string queryString = "SELECT DISTINCT CustomerID FROM Orders";
using (OdbcConnection connection = new OdbcConnection(connectionString))
{
OdbcCommand command = new OdbcCommand(queryString, connection);
connection.Open();
// Execute the DataReader and access the data.
OdbcDataReader reader = command.ExecuteReader();
while (reader.Read())
{
Console.WriteLine("CustomerID={0}", reader[0]);
}
// Call Close when done reading.
reader.Close();
}
}
FYI i am just copy/pasting these directly from MSDN. I highly recommend reading over their documentation and looking at their examples if you are just getting started.
http://msdn.microsoft.com/en-us/library/system.data.odbc.odbcdatareader.aspx

Here is a blog post getting you started with MySql and C#.
http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/
Hope that gets you started.
Bob