sqlite and vs.net 2008 3.5 / 64bit issue

[guest2013-1]

So Windows 7 64bit... I'm running that with VS.NET 2008 and I have a Winforms app (.net 3.5) that I use sqlite for (I have the relevant dll's installed from their site)

I go ahead/compile... and give the debug files (exe + dll's) to my friend. Also running Windows 7 64bit. And yet he can't run the program.

"But it works on my machine" syndrome kicks in... fire up Virtual PC on his side and figure out in 32bit mode it works perfectly.

Now I'm

On a 64bit environment (mine) it runs fine. Copying the files to another 64bit machine doesn't run fine (apparently there's 2 different dll's for sqlite). 32bit runs it perfectly each time.

WTF? Am I missing something here? Shouldn't this **** just work?

 

[FarligOpptreden]

Isn't this a target platform compilation issue? You made sure to set the target is x64?

 

[guest2013-1]

I have no idea what you on about... I press F5... that should do it right?

 

[Other Pineapple Smurf]

A quick google brings up one common problem with SQLite in that you need to check where the DLL is on your PC / dev enviroment and the deployed PC enviroment. Just do a search on both PCs.

Sometimes looking at the most basic problem sources is the best solution.

 

[guest2013-1]

Yea no tried that first, it is referenced from within the root of the program folder and I now "ship" it with the library, but apparently there's 32bit version and 64bit version. No idea why, but on my machine it runs great (probably automatically 32 bit or whatever) but on another 64 bit with the right references it doesn't.

Where is the days in vs.net where I could just reference something and it would be build/compiled with the damn exe...

 

[FarligOpptreden]

I have no idea what you on about... I press F5... that should do it right?

From VS2008: Right-click on the project, go to the Build tab, check the platform target (can be Any CPU, x86, x64 or Itanium).

 

[guest2013-1]

From VS2008: Right-click on the project, go to the Build tab, check the platform target (can be Any CPU, x86, x64 or Itanium).

I only have the "Any CPU" option. Could it have something to do with the sqlite dll? Because it bitches it couldn't read it even though the referenced path is relative to the folder the exe resides in... How do you include files into your project, I was always able to add it in the project and say "include in project" and whenever I compiled it was in the directory it was supposed to be.

And where the hell did the bin folder go to? Any dll's could just live in there and didn't need to reference all weird parts of a physical machine.... 2008 sucks

 

[FarligOpptreden]

Relax Acid... They're still there. If you add the Sqlite reference to your project, I assume you remembered to right-click on the References part of the project and chose "Add Reference" and browsed to the file. It should then be copied to your project's bin folder, either to the Debug or Release folder, depending on your project's configuration. Another option would be to click on the Project, go to Project in the Menu Bar and choose "Show All Files". Check that the file is in fact in your bin folder then...

 

[guest2013-1]

Relax Acid... They're still there. If you add the Sqlite reference to your project, I assume you remembered to right-click on the References part of the project and chose "Add Reference" and browsed to the file. It should then be copied to your project's bin folder, either to the Debug or Release folder, depending on your project's configuration. Another option would be to click on the Project, go to Project in the Menu Bar and choose "Show All Files". Check that the file is in fact in your bin folder then...

lol, yea I figured out today WHERE this actually happens. For some reason the sqlite library I installed comes with 2 versions of the dll (one for 32 bit and one for 64 bit) but when I reference it after it's installed, it loads the 32bit dll.

This also doesn't get included in the build (debug/release, I can't find that drop down?) of the project, so I checked out the "Debug" and "Publish" tabs and saw the DLL was excluded where the other dll I also referenced (not through VS.NET, but by "browse" function when referencing) was included. So I just included the sqllite dll when I build it. I then went under advanced options and changed from Any CPU to 32bit (as the drop down didn't allow me normally)... what is weird for me that something built with "Any CPU" on a 64bit system doesn't run on a 64 bit system, but I figured it was because of the dll not being read (error indicated that anyway)

this also didn't work when I included the sqlite dll file. For some reason it doesn't fall back trying to read the dll in the app directory when its not in the gac...

so I Published the project (never did it before so left on default settings with the dll also included instead of excluded... its under advanced options somewhere)

This appeared to work but it appears it was very hard to find (and installed somewhere REALLY arb) on the PC, so I'm figuring I'll set a default install path and try and publish/install on the system again to see if it worked. I just have to remember to included the actual database as well or create it from scratch on startup.

Do you know if there's an easy way to create the entire db from scratch based on a schema? or do I just export all the "create table" etc statements available to me?

 

[FarligOpptreden]

If you were to use MSSQL, you could've looked at Red-Gate SQL's products - VERY powerful, even allowing you to use their API to create / update databases. Unfortunately I don't have so much experience with Sqlite to recommend a similar tool for the job at hand...

But yes, the best would probably be to add your CREATE scripts in one, looooooong script, but DO NOT EXECUTE ALL AT ONCE. From an MSSQL perspective, I found it much faster to split the single script into a string[] based on all "GO" statements and execute each string individually. Running the roughly 9mb script as a whole took about 3 minutes, while executing each string individually took in total 40 seconds. So maybe the same would apply to other RDBMSs?

 

[guest2013-1]

Thanks, would check it out. I also have to plan for future upgrades to the database seeing as it's deployed with the application on the desktop. I'm used to having a central database environment where I can change things without having an impact on the actual program.