SQLite Problem loading module

[kylomas]

SQLite Experts,

I uninstalled both Beta (3.3.7) and Prod (3.3.6) versions of AutoIT. I then installed version 3.3.8.

I was unable to run a script using SQLite due to "SQLite.dll not found" so I followed JHCD's directions here

I was still unable to run this script until I added #requireadmin.

The script is started by DBL clicking a desktop icon pointing to a script source file. The statement that generates the error is

_SQLite_Startup ($sdll_filename = "c:dautoitsourcesqlite3.dll",$bforcelocal=1)

This behaviour started with 3.3.7 (beta). I got around it by running this under 3.3.6 (posted the problem but never resolved).

I am running this as a 32 bit app. I am not trying to write to the root dir of "c:", nor am I trying to change any windows or registry settings. Any idea why I need #requireadmin.

Just as an aside, I turned off UAC and tried to change permissions to write to the "program files" directory without sucess. This must be a Win7 thing and what other suprises await!!?!!

Thanks,

kylomas

[Beege]

Is that the actual code your using? It shouldnt be working at all. The default parameters for that function are:

Func _SQLite_Startup($sDll_Filename = "", $bUTF8ErrorMsg = False, $bForceLocal = 0, $sPrintCallback = $g_sPrintCallback_SQLite)

Going by your code it would need to be :

_SQLite_Startup ( "c:\d\autoit\source\sqlite3.dll",0,1)

[kylomas]

Beege,

Yes, that is the actual code and it work with #requireadmin...the function parms are NOT positional

kylomas

[Beege]

the function parms are NOT positional

Are you sure about that? Even if you were calling a custom _SQLite function, the parameters would have to be positional.. Calling the function that way would check if $sdll_filename is equal to "c:dautoit....." and then pass true or false to the function

[jchd]

Hi kylomas,

You're lucky I awoke right in the middle of the (my) night and had to lookup the clock at the computer!

I decided to dig further and asked a friend to give me remote control over a 64-bit PC.

I repeated the steps you mention: install old release, beta, full Scite, uninstall beta and release then install 3.3.8.0

I installed it as a x64 by default.

I tried to run the simplest example _SQLite_LibVersion() as x64.

It successfully downloaded the x64 DLL as C:Windowssystem32sqlite3_x64.dll and all was right.

Then I tried running the script as x86 and it worked as well, downloading the x86 version to C:WindowsSysWOW64sqlite3.dll

Now you're right about the fact that installing system components like this will raise UAC validation (UAC is disabled on the PC I had access to).

Also as Valik already pointed out, letting the download happen this way could easily put a heavy load on the server. Let me point out that I didn't touch this part.

Finally, Beege is right to say that parameters in AutoIt functions are positional. Your syntax evaluates the equality tests then passes the results (into the first and second parameters).

Edited December 27, 2011 by jchd

[kylomas]

@beege,

My apologies, terminology fubar...what I should have said is that the parameters are optional...

@jchd,

My rambling may have obscured the essense of the question. My script works with #requireadmin and does not without the directive and I do NOT understand why.

When I get through my current shit storm I am going to repeat what you just outlined. If I do not get the same results then I suspect that my environment is fucked up in some way...

Also,

Your efforts are HUGELY appreciated, thank you!

kylomas

[kylomas]

jchd,

I did the following:

1 - installed autoit 3.3.8 and full scite on a win7 laptop that had never seen autoit before (UAC enabled)

recieved UAC prompt as expected)

selected option to run 64 bit tools

2 - ran the _SQLite_LibVersion example from the help file

3 - recieved "slqite.dll can't be loaded" message

4 - added #requireadmin

5 - sqlite3_64.dll was copied to "C:\Windows\System32\" dir following UAC prompt

6 - commented out #requireadmin and re-ran script successfully

Conclusions:

The initial run downloaded the load mod from the internet to the windows dir. Subsequent runs no longer require elevated auth as it was the copying of the lmod to the windows dir that was causing the UAC prompt.

Additional Info

I went back to the pc experiencing the origional problem and ran the script with #requireadmin commented out. The script now runs with no problems.

SQLite3.dll is present in "c:windowssyswow64". IT must have been copied there by a previous run with elevated authority.

Summary

SQLite run "out of the box" after a clean install wihtout moving any files or specifying any additional parms.

Do you agree with these conclusions???

Again, thanks for your efforts,

kylomas

[jchd]

That looks like what is to be expected. You normally shouldn't have more issues now that the dll is there.

Anyway I doubt this is the right way to do it.

[kylomas]

jchd,

Why not, the lmod is downloaded once and you are set to go. OR am I misunderstanding this AGAIN?

kylomas

[BrewManNH]

Just make sure that if you distribute the script, that you include the dll with it, rather than having your script download it from the site. If you put the dll in the same directory as the script, you won't have any issues with UAC or admin rights for the distributed script, and you won't use the bandwidth of the site for no reason.

[kylomas]

BrewmanNH,

Thanks, I don't distribute any of this software yet so did not consider that. Maybe it makes more sense to copy the lmod to a user dir and fileinstall it when compiling. Agree?

kylomas

[BrewManNH]

You can use FileInstall to put it somewhere safe that doesn't require elevating the script's rights. If it's in the same folder as the script, you can access it using either @ScriptDir or just using a relative reference to it. The dll is small enough that it won't increase the size of a compiled script by a whole lot and it won't require the user of your script to be connected to the internet before they can use the script.

[jchd]

Correct, but as Valik pointed out in another part of the forum, suppose some admin makes a useful app which will be distributed on 5000 users: useless heavy load on AutoIt poor little server.

OTOH, installing the DLL in the script folder is fine (albeit using the script folder isn't the right place for a common dll), until you have 53 such applications with potentially distinct versions: defeating the purposes of DLLs.

I guess that the most reasonable way to handle this would be to drop the direct DLL distribution by AutoIt, that is not make it (in fact them: 32- & 64-bit) part of the distro (as before) not have it automagically downloaded (as today). The burden of fetching the right DLL, distributing and installing it in the most convenient place should be the decision and job of the app author. Having a copy of both 32- and 64-bit DLL in the latest revision for occasional download as it is available today here is a good idea anyway.

Automated download isn't a good idea and doesn't scale nicely: for instance, the full ICU support extension for SQLite or other applications is something like 18 Mib in 3 dlls...

There are real risks in placing the latest sqlite3 dll(s) in system folder, even if the SQLite team takes compatibility very seriously. Even if most typical PCs carry several copies of different versions of this component (several Adobe products, every FireFox, which are both very popular, Mathematica much less), the odds of hitting a really serious incompatibility is minimal at the SQLite API per se. All you would notice in case a more recent version is used is a speed gain in average use. The DB file format is fixed for v3 and cross-platform: you can work on your iPad SQLite DB with an AutoIt application using the standard UDF. Same for an SQLite DB created on a ARM platform and so on.

The problem with keeping only one version is that another product could rely on some extensions built in the DLL, whose absence would cause errors (e.g. FireFox).

Edited December 27, 2011 by jchd

[kylomas]

jchd,

I see, thanks for the info.

kylomas