Thank you for your reply. I didn't knew it, but it is a little far from my class.
Dapper does operations that my class doesn't and vice versa.
My main purpose is to avoid boring operations. I defined the connection only one time in my programs. When I ask for a select, my class will open the right connection. After a specified time that the sql was executed, if nothing else is happened, the connection will be closed and disposed. All the rest is only to simplify the Sql writing, nothing else. And the results know all that concerned the executed operations.
Dapper looks like a Pearl approach, send commands to have directly compiled objects or vice versa. I like much more when you can directly see all that is happening. My class hides boring operations, Dapper hides the important ones. I admit that Dapper sound nice. Maybe in future I will implement operations like its ones.
I use very much my class to debug operations, printing all operations that are involved and the produced results, I think I will not use Dapper instead my class.
Thank you for your suggestion. The project was created only to simplify the database management, not for specific automations. I.e. every calls with a select command pass that command to the database engine. A serie of complicated operations is required for the your purpose. Recognising the Insert command, recognizing that the table could have a auto increment field, write the select to search for the last autoinsert field and return it.
I suggest you to write a class that involves that automations, and all you like, that use my class for your desired scopes. Some time ago I started to write a class like this too, but I write only a few of scope and I saw that - In Italy we say - grief is greatest of pleasure. It was an aborted project. To make it very complete is so hard and every one will use only a little portion of it.
I like VB for historical reasons: I started writing in basic with the commodore C64 in the eighties. I was only 8 years old, and I didn't know any word in English, and the manuals were in English. I started to understand English reading them and trying to see how the different commands worked.
But I also wrote projects in C/C++/Java and C# in the time.
The differences between C# and VB are very tiny, but I like much more how error windows work in VB than in C#. And I like the use of the VB Static variables, that doesn't exists in C#.
I used C# to define classes with custom operators when VB did not allow to define them. Now, almost all you can do with C# you can with VB.
Write in VB ALWAYS using Options Explicit On and Option Strict On. In this way the performances are almost the same, otherwise VB can be up to some thousand times slower.
The downloaded file was not "cached", it was different from the first by 1k, once checked I deleted the first. The second file has the same name plus the usual padding of (1) to distinguish it from the first of the same name.
There is no solution file in the Database project, opening the Uso Database solution files produces the same Team Foundation error:
D:\My Documents\Visual Studio 2010\Projects\DataBase\DataBase.vbproj : error : Package 'Microsoft.VisualStudio.TeamFoundation.VersionControl.HatPackage, Microsoft.VisualStudio.TeamFoundation.VersionControl, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load.
Ok, I opened the solution with VS 2010 and saved it. The first time it warn be about the source code. The second one not. Now the Database.vbproj project file is a little bit different. May be this was the cause of that error.
In VS 2012, when I removed references to the Team Foundation in the solution file the projects was not referred any more to the Team Foudnation system. VS 2010 Not.