Buenas a todos.
Estoy con un problema, no soy de preguntar mucho pero me he encontrado con un problema o "BUG" dentro de Unity3D. Lo que quiero lograr es compilar un APK para android y empaquetar un Base de Datos SQLite, hace un tiempo lo implemente y todo funciono de maravillas, pero ahora no funciona, quizás me estoy olvidando de algo.Intento 1: Agregar la extencion ".db" para que sea Compilada como un recurso. <- No funciona Intento 2: Mover la base de datos a la carpeta "Resources", Tampoco funciona.Bien, lógicamente estas dos primeras no tendrían por que funcionar, ya que la base de datos si se crea dentro del APK, pero luego al ser instalada en el dispositivo la misma no se copia, es decir solo queda empaquetada en el APK.Intento 3: Cada vez que el juego inicia pasa por la siguiente comprobación ¿Existe la base de datos en /Ruta/Datos.db?, de no ser, utilizamos la carpeta "StreamingAssets" para poder cargar en RunTime la base de datos y copiarla a la ruta que deseamos. !ANDROID no deja que copiemos o movamos estos archivos a ninguna parte del telefono¡, algo bastante raro ya que programando nativamente jamas tuve esta clase de problemas. Esto es todo, pero tengo unas preguntas...
¿Alguien sabe como hacerlo de una mejor manera?¿Existe una alternativa SQL para utilizar con Unity?¿Cual de los 3 intentos parece mas factible? PD: El  "bug" es que en versiones anteriores los archivos puesto dentro dela carpeta Resources se copiaban a la ruta de instalación de la aplicación.  Verificando con Root Explorer en android, pude ver que esto no se estaba haciendo si bien el APK tenia el archivo, en la instalación este pasaba por alto.Un Abrazo a todos.

Depende del tamaño de los datos y su origen habrían diferentes opciones. Yo distinguiría en tres:1. Datos locales sin origen externo2. Datos locales con origen externo3. Datos masivos, manteniendo locales cache y externosCual encaja en tu tipología?

Estaría entre el 1 y el 2, es decir, necesito la base de datos con valores ya cargados, estos mismos desde el Editor y pero una vez compilado el juego la base de datos es Local y su gestión es interna.¿Se entiende?El Problema solo radica en que Android y la Compilación de Unity3D no están funcionando como pensé que debería, o como en un tiempo funcionaba.

Entonces es 1. Por qué el tipo 2 de origen externo?

Si 

    private static string FilePath = Application.dataPath + "/StreamingAssets/Datos.s3db" ;

public static string GetFilePath
{
   get
   {
      #if UNITY_ANDROID
      if(!File.Exists(FilePath))
      {
         WWW loadDB = new WWW("jar:file://" + Application.dataPath + "!/assets/Datos.s3db"); 
         while(!loadDB.isDone) {} 
         File.WriteAllBytes(FilePath,loadDB.bytes);
      }
      #endif
      return "URI=file:"+FilePath;
   }
}

Esto es como supuesta mente tendría que estar para su funcionamiento en Android

Intentalo con la carpeta plugin o ponle otra extension  al archivo como txt o jpg.

Para tu tratamiento de datos siempre local, create una lista con el tipo de registro que quieras y utiliza linq para acceder.No necesitas una bbdd.

[quote author=iRobb" data-ipsquote-contapp="forums" data-ipsquote-contenttype="forums" data-ipsquote-contentclass="forums_Topic" data-ipsquote-contentid="32985" data-ipsquote-contentcommentid="121289 date=1445708274]Para tu tratamiento de datos siempre local, create una lista con el tipo de registro que quieras y utiliza linq para acceder.No necesitas una bbdd.[/quote]No se en que te basas para decirme que no la necesito, creo que una base de datos es algo muy útil, y de echo mi proyecto si lo necesita, no es que quiera armar problemas, pero pregunté si existía una solución o alternativa de base de datos (SQL), justamente por que ya pase la etapa de Diseño, donde se opto por una base de datos como la solución más óptima. Otra cosa, ¿Listas? usando ¿LINQ? Te das una idea de lo lento que puede ser esto cuando generas solo 3000 registros, dependiendo de qué datos están almacenando puede servir, pero que los datos no sean externo no quiere decir que la aplicación no va a generar nuevos registros de echo estimamos unos varios registros topes que se pueden generar solo en un apartado de la aplicación. De todos modos muchisimas gracias por comentar, un saludos a todos, luego subo la solucion al foro.

Tampoco mencionabas el volumen, sino que es sobre Android. En mis opciones mencionaba datos masivos aunque todos los vas a implementar en local solamente.Al final LINQ genera código SQL, pero tiene muchas ventajas de escalabilidad. De entrada, puedes implementarlo sobre lo que quieras, incluido SQLite o Listas. Si en el futuro cambias de gestor de bbdd o implementas algo más sofisticado, como decía en el apartado 3 (caché local + bbdd externa) lo tendrás más fácil en LINQ que en SQL directo, ya que podrás discriminar los datos locales de los remotos.Ahora bien, si lo que haces es 3000 inserts en un corto espacio de tiempo, ahí ya depende el tamaño de registro, índices, etc. más que de SQL. Pero vamos, es una situación atípica en un dispositivo móvil, ya que son en general transaccionales. Eso faltaba por mencionar.
Por tanto y resumiendo, si tu preocupación es insertar 10000 registros lo más rápido posible y con el mejor rendimiento (en plan bulk load) utiliza HashSet. Nada va a ser más rápido. Ni listas ni bbdd ni sqlite.http://theburningmonk.com/2011/03/hashset-vs-list-vs-dictionary/" rel="external nofollow">http://theburningmonk.com/2011/03/hashset-vs-list-vs-dictionary/ 

[quote author=iRobb" data-ipsquote-contapp="forums" data-ipsquote-contenttype="forums" data-ipsquote-contentclass="forums_Topic" data-ipsquote-contentid="32985" data-ipsquote-contentcommentid="121620">Tampoco mencionabas el volumen, sino que es sobre Android. En mis opciones mencionaba datos masivos aunque todos los vas a implementar en local solamente.Al final LINQ genera código SQL, pero tiene muchas ventajas de escalabilidad. De entrada, puedes implementarlo sobre lo que quieras, incluido SQLite o Listas. Si en el futuro cambias de gestor de bbdd o implementas algo más sofisticado, como decía en el apartado 3 (caché local + bbdd externa) lo tendrás más fácil en LINQ que en SQL directo, ya que podrás discriminar los datos locales de los remotos.Ahora bien, si lo que haces es 3000 inserts en un corto espacio de tiempo, ahí ya depende el tamaño de registro, índices, etc. más que de SQL. Pero vamos, es una situación atípica en un dispositivo móvil, ya que son en general transaccionales. Eso faltaba por mencionar.Por tanto y resumiendo, si tu preocupación es insertar 10000 registros lo más rápido posible y con el mejor rendimiento (en plan bulk load) utiliza HashSet. Nada va a ser más rápido. Ni listas ni bbdd ni sqlite.http://theburningmonk.com/2011/03/hashset-vs-list-vs-dictionary/ date=1445825435]http://theburningmonk.com/2011/03/hashset-vs-list-vs-dictionary/ [/quote]IRobb, Creo que no nos entendimos, entiendo todo lo que me dices, pero no necesitaba una Base de SQLite, solo preguntaba eso, se que es bueno que muchas veces comenten alternativas, pero ya conozco las alternativas que me mencionas y he decantado por SQLite para este proyecto por varias razones.De todos modos Gracias.