I am using Sqlite ADO.NET provider 2.0 in my c# application .net framework 4.0.
Question1: Does this .dll come with a back up Database functionality?. If the suer wants to backup, looks like I have to get the source code and write my own backup feature.
Or is it already provided and I just need to use it?
Question2 :
I tried downloading a recent version of Sqlite ADO.NET provider(line 3.5/4.0)
from this website
http://www.sqlite.org/download.html/
sqlite-dll-win32-x64-3071300.zip
After attaching the dll as reference, it still says
Version v2.0.50727.
Description: ADO.NET 2.0 Data Provider for SQLite. Is this correct stable version or is there a recent one to be used.
Thank u
For Question 1: The ADO.NET provider isn't meant to have a backup capability. That's something the RDBMS software should have. ADO.NET is just a tool used to simplify communicating with the RDBMS.
- However, SQLLite backups are documented at http://www.sqllite.org/backup.html
For #2 I don't see a question - just a statement that you got a warning from Visual Studio. BUT based on what I'm seeing, you will get an error. You're trying to use an SqlLite provider for .NET 3.5 or above, and your .NET project is set to 2.0. Either upgrade your app to 3.5 or above, or look for an older .dll to download and use.
As a general rule of thumb, in a .NET project, you can use .dll files specified for an older version of the Framework, but not .dlls specified for newer versions.
Related
I've added the latest .Net Provider for DB2 to my project. It seems to add half of IBM's source to my project :|
Seriously, there is an almost 80MB clidriver folder in there now. I'm assuming IBM still hasn't gotten around to making this provider fully managed after 20 years.
Do I need this folder when I deploy the code? What about for .Net Core? Do I need to build it separately for Linux?
The docs aren't great on what this is for.
I've just started coding in Visual Studio Code with .NET Core, on Ubuntu 14.04.4
I'm used to both using Ubuntu (from personal interests, hobby, etc) and .NET and Visual Studio at work.
But I've run into a problem i can't seem to overcome. I'm building a small console app that i want to communicate with a MySql Server, but I can't seem to get the MySql.ConnectorNET.Data working properly.
It was installed with the command dnu install MySql.ConnectorNET.Data And that seemed to work fine. The dependency was added in the project.json file, and intellisense was able to traverse the package just fine, but the OmniSharp Log reports that:
[INFORMATION:OmniSharp.Dnx.DnxProjectSystem] Project /home/<username>/VSCode/SimpleSQLatmpt/project.json has these unresolved references: MySql.ConnectorNET.Data
and I simply can't seem to fix that. VSCode seems to detect it, and asks me to run the dnu restore command. But it's to no avail. For all intends and purposes it seems like MySql.ConnectorNET.Data is available in the project, but just can't be used.
Can any one tell me how to fix this?
And just as important, why it is happening in the first place?
Thank you very much for your time.
At the time of this question (Mar 2016) there was no .NET Core-compatible ADO.NET provider for MySQL.
Now situation is changed:
MySqlConnector written by Bradley Grainger -- licensed under MIT, and offers full async support
MySql.Data (>6.10) provided by Oracle (traditionally, GPL)
Personally I prefer MySqlConnector -- it can be used in commercial projects for free (MIT license); also I've tested it with my NReco.Data library under Linux, and it works perfectly in my scenarious. Unfortunately, MySqlConnector doesn't support EF Core yet.
--- UPDATE --
One more .NET Core-compatible MySQL connector + EF Core MySQL provider:
Pomelo.Data.MySql (unfortunately it doesn't implement true async behaviour)
Pomelo.EntityFrameworkCore.MySql
UPDATE 2
MySql Connector NET for .NET Core 1.0 was just released (Sep 2016)
http://insidemysql.com/mysql-connector-net-for-net-core-1-0/
I didn't try Bradley Grainger's connector, but this one from MySQL do not support SSL. :(
So, anybody who wants to use anyway, should connect with ";SslMode=None;" in the connection string.
First of all, I want so say I read the other questions and none of them helped me.
The server where I'm getting this error is a Windows 2003 SP2 + .net framework 4.0 + Oracle i9 client
I have downloaded the latest ODP.NET ODAC1120320Xcopy_32bit.zip a copied these dll out.
oci.dll
ociw32.dll
Oracle.DataAccess.dll
orannzsbb11.dll
oraocci11.dll
oraociei11.dll
OraOps11w.dll
I've created a little app which just connects to an oracle. link
And when I run this app I'm getting the The provider is not compatible with the version of Oracle client error.
On the download page was also written : Each 32-bit ODAC client download below supports connectivity to Oracle Database versions 9.2, 10.1, 10.2, and 11.1, and 11.2.
So I guess I should be fine with my 9i database.
I'm not sure if I should use some older ODP.NET version. One answer here on SO sugested to use version 11.1.0.6.20 which supports the .NET 2.0 but my application is written against .NET 4.0.
What can I do ?
I'm unaware of any supported method of running an oracle client without some sort of install (the xcopy version includes a batch file for installation so the "xcopy" is a bit of a misnomer.
That said, if you're going to do something that's unsupported, you might as well go with something that WILL eventually be supported - the 100% managed provider (meaning no extra unmanaged dlls to copy) is currently in beta:
http://www.oracle.com/technetwork/database/windows/downloads/odpmbeta-1696432.html
I am suborn to see something to the end even for just the learning experience so I'd understand if you wanted to see your current way to fruition. The oracle documentation does indicate that the application directory is in fact first in the unmanaged dll search order. My guess is that additional dlls are needed (you are using a newer version than your linked article). I would see which specific dlls it's loading from outside of your app directory using a tool like Process Monitor and see if you can find the equivalents from the new ODAC to copy over.
I just want to make it sure that this ODP.NET is the native provider for oracle design for .net and since when exit's? because some of my partners say that it's pretty new and want to know when was the first release. This all discussion came because they chooses not used entity framework because oracle was not release a native provider for .net in the 2008 and want to check if it's true
Originally the Net Framework 1.1 provided a native Oracle ADO.NET provider in the namespace System.Data.OracleClient, but then Microsoft declared it obsolete and stated that these types are deprecated and will be removed in a future version of the .NET Framework. (But are still here in Net 4.0). In the meantime Oracle build ODP.NET and now this could be considered the official Oracle Net Provider.
You can download it for free here
It comes in 32bit and 64bit versions and, as stated by Oracle, it includes Entity Framework, LINQ, WCF Data Services, and implicit REF CURSOR parameter binding support.
At this link you could read numerous FAQ on this provider
I can't find a template for a linq to sql class in .net 2.0 project, based on what i know you can work with linq in .NET 2.0 as long as you have 3.5 in your development machine and ship system.core.dll with your application?
so based on that how can I add a Linq to Sql model to my project when "Linq to Sql Classes" template is missing from the add new item window?
Edit:
Just to clear things up, This is a server application and the server will have .net 3.5 SP1. the only issues is that we can not upgrade the project to .net 3.5 at the moment.
If you ship System.Core with your application, it won't pick up future security fixes and won't have the optimized build installed (MS internally uses and profiling NGEN for distributed framework libraries). Either require .NET 3.5, avoid using Linq, or implement your own extensions for a custom Linq provider.
The approach you are taking is dangerous and will almost certainly lead to errors on your deployment machine.
The 3.5 framework, and specifically System.Core.dll, rely on the CLR being at least 2.0 SP1. There are several bugs in CLR 2.0 that are exposed by the use of the expression tree API and other code which Linq2Sql relies upon.
If you ship System.Core.dll only the clients are not guaranteed to have, and likely won't have, the CLR service pack. Hitting any of these bugs will result in hard to understand failures in your application.
You may get lucky for awhile but this is an untested and unsupported scenario.
I highly advise you to not do this
Try adding a reference to System.Core
http://iformattable.blogspot.com/2008/05/using-linq-from-net-20.html
I figured it out, All you have to do is add a new text file to the project, but change the extension from .txt to .dbml and it'll automatically be picked up by visual studio. it will even generate all the code behind for you.