System.data... dll issues

Assets/SQLITECLASS.cs(8,12): error CS0234: The type or namespace name `Data' does not exist in the namespace `Mono'. Are you missing an assembly reference?

Assets/SQLITECLASS.cs(9,14): error CS0234: The type or namespace name `Data' does not exist in the namespace `System'. Are you missing an assembly reference?

Why since 2.x have I had to ALWAYS copy the System.Data.DLL and the Mono.Data.Sqlite.dll along with the sqlite3.dll to the Assets folder? I have bug report on this from way back when, these should be known by Unity regardless, so why has it been simply ignored this entire time? Is there a particular reason why System.Data.dll and Mono.Data.Sqlite.dll are left out of the "known libraries" that Unity is aware of?

 

To add pain to punishment, I am REQUIRED to have the System.Data.DLL in the Assets folder to BUILD anything otherwise I get script compile errors, but when I try to deploy to android it says

So I can NOT build and deploy because if I remove the DLL's, it refuses to build because of compile errors missing System.Data but if I have them it refuses to deploy because assembly's already found, son of a...

I have to use SQLITE 3 in Andriod which IS supported by Andriod but apparently not by Unity and Andriod.. sigh

 

zumwalt, are you having the same issues on the iPhone?

The included project works for me. YMMV.

I don't have android so I can't test it there.

1. Open the Project
2. Update the bundle Identifier
3. Build Settings Build
4. Open Xcode Project
5. Add the SQLiteTestDB from the project directory to the Xcode project using - Option-Command+a (don't copy)
6. Build and Run

 

After confirming that basic connectivity was working in a in a fresh project, I tried to apply it to my main project and ended up blowing off about 2hrs of wasted time due to this cryptic error message. :-x

Code (csharp):

1. (Filename: /Applications/buildAgent/work/68355d6e5d19d587/Projects/../Runtime/Export/Generated/BaseClass.cpp Line: 2535)
2.  
3. * Assertion at icall.c:4949, condition `create_culture' not met
4.  
5. Program received signal:  “SIGABRT”.
6.  

It turns out that having "Strip assemblies" enabled causes this error.

dreamora or andeee, if your reading this, is this behaviour to be expected or should I file a bug report?

 

that stripping cuts stuff you might need is generally nothing new but normal as the stripping has a focus on the assemblies unity offers without copying around any manually.

my general workflow is to test without stripping and then test. if it works, I go through step by step on the stripping level till I find the one breaking and then return to the last working.
i do that once all is ready, doing it before is pointless.


also ensure to not use scrollviews or not using stripping as the two things together basically mean "dead" (mention this is scrollviews would be rather normal along db usage as you need to present the data somehow)

 

My MacBook Pro is at work, I will give this a try with it tomorrow, The thing is, they seem to have blocked System.Data.dll and the Mono SQLLite from deploying to the Andriod phone, and I need to use System.Data for other purposes besides simple SQLLite, I am not sure if the deploying between the two phones is different in some way, I would think what works on one should be allowed to work on the other, but each platform as a totally different developer base.

 

on android a problem that comes in is that not all stuff is present on the NDK layer so its to expect that not all comes through. anything that relies on the android os offerings must be done through java binding I fear

 

Unlike the iPhone with XCode, I have no direct access to the build of the package to be able to utilize the SQLLite without using the Mono version, so are saying that the System.Data use for datatables etc and the Mono SQLLite will simply not work in Unity with Andriod? Since my programs are being built for multiple platforms, I have to include the Using statement at the top for all libraries in use, even if they won't be used for certain platforms, so in code I can have statements to ignore code blocks based on platform, but in none of that can I ignore Namespaces, only Unity internally can do that, so why is Unity simply not "ignoring" namespaces that are not valid for certain OS's? This way I do not have to have multiple versions of the same game with dragging DLL's in and out, along with dragging script files in and out based on which OS I want to build for? Why would Unity not allow the native SQLLite 3 use from the Andriod phone and not even talk about it anywhere in the documentation? Why would they not include those files in the normal form of the program so that those namespaces are already known?

I guess I have a ton of "why" questions, I am working on a way around the SQLLite issue for the Andriod phone if I can get PlayerPrefs to work right for me every time (not to mention Application.Quit refuses to work 80% of the time), it is a PITA to have to drag libraries in and out and have to drag script files in and out depending on which OS I want to build the app for instead of having conditional statements based on platform type....

 

I'm not saying anything like that but I'm reminding you that the android as OS is built around the usage of java, many libraries are accessable only on that level, they don't have hooks for native code usage and as such system.data might very well just fail because there is no sqllite3.so present for NDK usage (as there is on the iphone)
this basically holds for any namespace that relies on external libraries being present

Don't forget: System.data on its own does exactly nothing, it fully relies on the presence of a native platform library or will not work.

The android is not even remotely like the iOS in such things, as you will realize at latest when you hope to add extra functionality and fight your way through the unity -> native code -> JNI -> java (if you want to use androids java vm, otherwise you use the .net java vm)

 

Just great.. so then.. the reading I have done so far on the JNI, I am still unsure how to "hook" into SQLLite in Andriod from links:
http://developer.android.com/guide/topics/data/data-storage.html#db
http://en.wikipedia.org/wiki/Java_Native_Interface
http://docwiki.unity3d.com/index.php?n=Main.Plugins#AndroidPlugins

My problem, I can't figure out in Eclipse how to write a java plugin, I mean code wise, I am trying to find example Eclipse java code that works with Unity to talk to the Nexus...

 

Was issue of access to SQLLite from Unity Android ever resolved? I can't find a working example anywhere.

Native iOS has Core Data and Native Android has build in SQLLite wrappers. Seems pretty critical that Unity support some usable client db with both a client *AND* a 'server'/db impl that can run locally on device (and PlayerPrefs is NOT a client db).

 

Change on PlayerSettings for Android API Compatibility to .NET 2.0 (No Subset).

 

Try Using
SqliteConnection
SqliteCommand
SqliteDataReader

instead of IDb Versions

 

I was having the same problem and this worked perfectly