#INCLUDE SQLite.ahk - Functions to access SQLite3 DB's

*deleted*

Oh, I suppose it is a follow-up of http://www.autohotke...opic.php?t=8324
Thank you for sharing, I am sure lot of people will find this interesting.
The alternative is Cheetah -- lighter, but less common, no SQL.
Or the big MySQL...
Or using ODBC for abstracting the database.

Oh, I suppose it is a follow-up of http://www.autohotke...opic.php?t=8324

Yes, you're right. There was not much response, but I wanted to have it, so I went on.

The alternative is Cheetah -- lighter, but less common, no SQL.
Or the big MySQL...
Or using ODBC for abstracting the database.

I don't know Cheetah, but in my opinion AHK and SQlite seem to be perfect for each other. To deploy tools, no installation is needed, you have only to copy the script.exe and the SQLite3.dll (and SQLite3.exe, when used) into the same folder (or SQLite... into the system path) for direct, simple and fast database access with SQL support. I like it.

I like your introductory remarks and the nicely structured script. Thanks for creating and sharing this resource.

Thanks for your work.

The sample script returns an error message

Error at line 159.

Line Text: SHOW_LISTVIEW
Error: Duplicate label.

Dirk

Dirk, remember to use a nickname, even if not logged in, thanks.
You should do a search in the code you try to run. Searching SHOW_LISTVIEW in the topic shows it only thrice: a Gosub, the label definition, and in your message.
Perhaps you accidentally pasted the code twice?

I copied the script one again. Error message remains.

Dirk

I had no problems with the script. It works fine. The issue must be on your end.

It was indeed on my end.
Sorry!
Dirk

OK, as I noted in the thread I had started thanks again for this module. In my excitement I have been up way past the time I should be sleeping however trying to figure out an error I am having.

I am sorry for what may be a double post, however I wanted to make sure I got this in the right spot since you started a new thread. I also realize the above person's note that 'it worked for them so it must be on my machine'. I wouldn't disagree, however I could use some pointers if someone has any as to what might be the cause.

On my first run, I had experience a strange error where the program was overwriting itself replacing items with 'name name' as I mention in the original thread here http://www.autohotke...opic.php?t=8324

However I started fresh and now I am getting another error that feels similar stating: Error in #include file "C:\dev\sqliteahk\SQLite.ahk": This DllCall requires a prior VarSetCapacity. The program is now unstable and will exit. It no longer hard crashes to the point it wants to send a note to Microsoft (as it did in my first error description) however it does still fail after showing the 'Last Insert ID'. It is not overwriting the code with various pieces of 'Name Name'

Now I have made sure I am on the same SQLite version, and have moved from 3.7 to 3.8 without any changes. I had 1.0.45 of AHK installed, and that was when I had the first error described (name name replacing items in the running file). I tried downgrading to 1.0.44 as the author points out in the source with no change, however when I moved up to the latest version that is when the error did change.

Again, any thoughts on what I may have done wrong here would be appreciated. I look forward to implementing all kinds of goodies using SQLite which I didn't have the ability to complete myself - KUDO's.

This is because AutoHotkey has become, with latest version, more picky on the size of variables used as buffer, ie. where the WinAPI will write.
That's a good thing, the old versions probably has hidden side effects, like memory overwriting.

Quick fix: Search in the code all the "UInt *" declarations in DllCalls.
Look at the variable name after this declaration. It is, most of the time, initialized like $h_DB := 0. Just change 0 to 0000 and it should be OK.
In _SQLite_Exec, $iErr isn't even initialized, add a $iErr := 0000 line after $i_RC init.

I suppose nick will update his script. nick, I suggest you remove the code pasted in the message and upload the file to AutoHotkey.net, if possible. Above a given number of lines, this becomes impractical. Thanks.
Note that the sample can remain there, it is rather small and it gives an idea of what the API looks like.

I fear the day the v.2 will be out... Will lot of scripts no longer working, we will have lot of similar messages...

I suppose nick will update his script. nick, I suggest you remove the code pasted in the message and upload the file to AutoHotkey.net, if possible. Above a given number of lines, this becomes impractical. Thanks.
Note that the sample can remain there, it is rather small and it gives an idea of what the API looks like.

Hello PhiLho and valenfor,

I'll try to find out what's wrong, but it may need a few days. I'll also follow the suggestion to move the script to AutoHotkey.net.

See you!

I'll try to find out what's wrong, but it may need a few days.

Please, re-read my post, I explain how to correct it... I didn't tested it, though! Some issues might remain.

Thank you for the tip. I did the changes you suggested PhiLho, however the error still persisted. I traced back and found that when this call was made inside _SQLite_GetTable the $s_Col doesn't have its capacity set. So, just trying to find the solution I added this line as shown in the code below:

VarSetCapacity($s_Col, 1024)

   VarSetCapacity($sResult, $i_GetRows * $iCols * $iCharSize)
   VarSetCapacity($s_Col, 1024)
   $i_Off := 0
   Loop %$i_GetRows%
   {
      $s_Row =
      Loop %$iCols%
      {
         $s_Col =
         DllCall("lstrcpyA"
               , "Str", $s_Col
               , "Uint", _#SQLite_ExtractInt($p_Result, $i_Off))
         $s_Row = %$s_Row%%$s_Col%|
         $i_Off += 4
      }
      StringTrimRight $s_Row, $s_Row, 1
      $sResult = %$sResult%%$s_Row%`n
   }

This did fix the problem and it ran. I realize that the column size should be calculated, however I wanted to see if I at least found the right location. Just figured I would post in case it saves you some time Nick.

Thanks again for the help.

Val.

This did fix the problem and it ran. I realize that the column size should be calculated, however I wanted to see if I at least found the right location. Just figured I would post in case it saves you some time Nick.

Hi,

I fixed it too, but too late!

What do you think about an additional optional parameter like iMaxLength=256 to pass the maximum column width to the function whenever needed?

THX for using the script and supporting me!