I am trying to test out some Dapper stuff using LinqPad.
Dapper needs a SqlConnection (IDbConnection really) to work. I could construct my own in the code window, but I thought if LinqPad already had made one, I would just use that.
Does LinqPad have a SqlConnection object already hanging around that I could use?
Did you try this?
this.Connection
It's a DataContext, after all.
Related
I just started using TypeORM as my main ORM for my server. I have seen some tutorials where they use createConnection() instead of creating a DataSource object and initializing it.
Are they different? Do they have different use cases?
Thanks.
createConnection() is the old way to do it. Since typeorm 0.3.x you should use the DataSource object with DataSource.initialize().
I am converting old VB6 app to newer VB.NET application and see these 3 lines often after the upgrade:
rs.Close()
'UPGRADE_NOTE: Object rs may not be destroyed until it is garbage collected. Click for more: 'ms-help://MS.VSCC.v80/dv_commoner/local/redirect.htm?keyword="6E35BFF6-CD74-4B09-9689-3E1A43DF8969"'
rs = Nothing
Where rs is of type RecordSet like so:
Dim rs As ADODB.Recordset
rs = New ADODB.Recordset
Should the last
rs = Nothing
line still exists? Or
rs.Close()
is enough?
With VB.Net, you pretty much never set objects to Nothing. That was common in the VB6 era, but with .Net it's no longer helpful, and can in rare situations be actively harmful. What you should do is use the Finally section of a Try/Catch/Finally block (or the Using block for a shorthand) to make sure objects that implement the IDisposable interface have their Dispose() function called in a timely way, and in the case of the old ADO objects the Finally block is the place to call .Close(). You especially want to do this for the ADO connection object.
In summary, the rs = Nothing line should not exist, but rs.Close() isn't enough by itself, either.
But that's really a side issue here. If you're converting to VB.Net, the best thing is to also convert from the original ADO to the more modern ADO.Net, which is more idiomatic for VB.Net. This means using DataSet and DataReader instead of RecordSet in the first place.
Finally, this is also a good time to review your queries and make sure they are using query parameters rather than string concatenation. Hopefully you were already doing this, but there is a lot of old and scary-vulnerable classic-ASP and vb6 code out there, and a .Net migration is a good time to plug those holes. Sql injection isn't something to fool around with.
I have a simple line in C# that I'm trying to translate to VB.NET and I'm getting nowhere.
(new CMachine()).Init();
Yes, It needs to be a 1-liner because the point I'm trying to demonstrate is that an instance of CMachine need not stick around after Init() has been called. Later in the code, I demonstrate subsequent instances of CMachine have already been initialized.
FYI: New CMachine().Init() and (New CMachine()).Init() do not work.
There may be a more idiomatic way of doing this, but this works:
With New CMachine
.Init()
End With
I'm using RhinoMocks, and according to this post it should be possible to mock an IDataReader.
However, I'm using VB instead of C#. My stub is written like so:
reader.Stub(Sub(fnord) fnord("ColumnName")).Return(expectedId)
But it tells me that "expression is not a method".
Is there any way to do this in VB, or do I have to use C# if I want to mock an IDataReader?
Try the following:
reader.Stub(Function(fnord) fnord("ColumnName")).Return(expectedId)
As you are writing the lambda for a function instead of a subroutine, you need to use Function instead of Sub.
I haven't touched VB in a few years, so apologies if this does not help.
I have built a wrapper DLL for a database that gives me an object API layer for my database. Where I am having issues is that the Garbage Collector in VB.net doesn't seem to be cleaning up the mess when I destroy the objects. I am relatively certain that I have done everything to clean up the object, including implementing the IDispose interface on every object to destroy everything.
Where things get ugly is when I instantiate the object, I do a database read and populate the object based on it's corresponding entry in the database. This works well, however, when I iterate through the creation and destruction of 1000's and 1000's of these objects, the memory just keeps ramping up.
Then it occurred to me: Could it be that my objects won't clean up because I am using a shared ODBC database reference inside my objects? would that keep my objects alive despite my best efforts?
For example: (note: clsSharedConfig.g_objDatabaseConn is a shared ODBCConnection instance)
Dim cmd As New OdbcCommand("SELECT * FROM FILES WHERE CID = " & p_lngID, clsSharedConfig.g_objDatabaseConn)
Dim data As OdbcDataReader
Try
cmd.CommandType = CommandType.Text
data = cmd.ExecuteReader()
Can anyone offer any other reason I am having this happen? I don't want to have to resort to shoving GC.Collect statments in everywhere to keep this under control!
Thanks,
Andrew
You have to close the reader to free up resources. See below
Private Sub CmdReaderSample(ByVal cn As OleDbConnection, ByVal strCmd As String)
Dim cmd As OleDbCommand = New OleDbCommand(strCmd, cn)
cmd.CommandType = CommandType.Text
Dim objReader As OleDbDataReader = cmd.ExecuteReader
Try
'read some stuff objReader.Read()
Finally
objReader.Close()
End Try
End Sub
Also check when your objects are loaded from reader, you maybe keeping a reference there as well.
Memory leaks are better chased by using memory profiler like Ants memory profiler
Have you tried just instantiating a new connection object each time? the .net framework will handle the actuall connection pooling under the hood, so I'm not sure that trying to share that object helps you alot anyhow.
So, I tried your suggestions (thanks BTW!), but alas, no change...
Then, just for a larf, I was looking around in the application settings for my DLL. I noticed that for some dumb/unknown reason, I had COM compatibility turned on.
So, I unchecked that, on the premise that I didn't NEED COM compatibility and that was just muddying the waters in finding a solution. As soon as I did, and I re-ran it, The memory leak was GONE!
Seriously? that was IT? I need someone to 'splain that one to me slowly, perhaps using hand puppets.
A memory profiler confirmed that my leak was in unmanaged memory.
that's 2 days Im not getting back...
Andrew