AutoHotkey Community

It is currently May 26th, 2012, 1:09 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: January 4th, 2009, 7:01 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
This is not ready for prime-time yet, but the Trac site, SVN, and Wiki are up:
Wiki: http://wiki.singularityshift.com/wiki/ahklitening
Trac: http://trac.singularityshift.com/projects/ahklitening
SVN: http://svn.singularityshift.com/svn/ahklitening

I've been trying to decide between the various ways of storing information in the various parts of SteamLab, and in doing so decided it would be really great if there were a modern and tightly integrated library of SQL-like functions for AHK.

I saw some functions designed to use the Cheetah DLL, and got to looking at the company's website who makes it. Their newer product, SQLitening, looks awesome and is based off of SQLite3.

I decided to take a crack at creating a library of functions for manipulating SQLitening databases.

1. First I am re-creating all of the DLL routines as wrapper functions, allowing easier access and additional functionality as required.
2. Second, I'll be creating helper functions to chain routines together and make working with the database easier

My goal is to have a drop-in, extremely lightweight SQL solution for anyone in AHK wanting to store data in a database. Just drop 2 or 3 small DLLs into your script directory, and you can utilize an SQLitening database in your application as if it were a native AHK feature. In fact, I'm trying to make this as much like a built-in library as possible (the goal of step 2 above).

I'm definitely open to comments and suggestions (and help :) ). Expect to see a first beta release within the next few days.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Last edited by bmcclure on January 9th, 2009, 1:13 am, edited 2 times in total.

Report this post
Top
 Profile  
Reply with quote  
PostPosted: January 4th, 2009, 8:14 am 
Offline

Joined: March 25th, 2007, 5:19 am
Posts: 44
bmcclure wrote:
I've been trying to decide between the various ways of storing information in the various parts of SteamLab, and in doing so decided it would be really great if there were a modern and tightly integrated library of SQL-like functions for AHK.

I saw some functions designed to use the Cheetah DLL, and got to looking at the company's website who makes it. Their newer product, SQLitening, looks awesome and is based off of SQLite3.

I decided to take a crack at creating a library of functions for manipulating SQLitening databases.

1. First I am re-creating all of the DLL routines as wrapper functions, allowing easier access and additional functionality as required.
2. Second, I'll be creating helper functions to chain routines together and make working with the database easier

My goal is to have a drop-in, extremely lightweight SQL solution for anyone in AHK wanting to store data in a database. Just drop 2 or 3 small DLLs into your script directory, and you can utilize an SQLitening database in your application as if it were a native AHK feature. In fact, I'm trying to make this as much like a built-in library as possible (the goal of step 2 above).

I'm definitely open to comments and suggestions (and help :) ). Expect to see a first beta release within the next few days.


That would be SO TOTALLY AWESOME!
=D

_________________
I would like to think that I know what I'm doing, but there's just to much stuff I've yet to learn...


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 4th, 2009, 8:53 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
Indeed; I'm about half way done now creating the wrapper functions, and just reading about them is making me antsy to test this out and get it released!

Not only will it be able to work directly from the database file (the way I'll be using it for starters), it will also natively support connecting to a remote (or local) SQLitening server and working with databases in that way.

Currently I'm naming the library SQLt, making it as short as possible while hopefully keeping it descriptive enough (and unique). I haven't done enough research into other functions that are available--if this turns out to be a commonly used library, it could probably eventually just become the SQL library in AHK. ~Dreams...~

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 7th, 2009, 12:21 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
Hold please :)

I'm currently fighting through a few DllCall issues which I haven't run across before (with my limited DllCall experience).

With all but one of the functions, I am nearly finished. I have some code cleanup and a few fixes to perform to make sure I'm allocating the right amount of memory for my passed variables etc.

The one I'm stuck on is figuring out the best way to handle the array that is returned from the slSelAry function. I'm hoping to be able to convert it to another array format that is easier to parse with AutoHotKey.

Expect this to be done within a couple of days. Thanks.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 9th, 2009, 1:01 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
Added the links to my development site and files in the first post.

Feel free to check out my progress or contribute code.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 9th, 2009, 6:08 am 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
Possibly an amateur mistake in assuming that this Dll would work with AutoHotKey, as I seem to be having some issues.

I've uploaded my current code to the SVN server in the first post, and can post a snapshot of it directly in the post if need be.

Here's the problem.

From the help file:
Quote:
slOpen ([rsFileName String, rsModChars String]) Long
FileName is the SQLite file to open as a database. There are two
special file names:
1. :memory: = opens an empty database in memory
2. empty or omitted = opens an empty temporary database on disk
FileName may also contain an optional password. This password
is separated from the file name by the $BS character.
ModChars:
C = Create if not there. Ignored if ReadOnly.
Em = Return errors. This will override the global return errors flag.
m is the optional message display modifier and can be:
0 = No message is displayed. This is the default.
1 = Display a warning message with OK button. Error is
returned when OK pressed.
2 = Display a question message with OK and Cancel buttons.
If they press OK, error is returned. If they press
Cancel, will exit process.
e = Do not return errors, display message and exit process. This
will override the global return errors flag.
R = ReadOnly.
Tn = Where n is milliseconds to wait for a database lock.
Defalut is 10000 milliseconds (10 seconds). If running
in remote mode then the TCP SEND/RECV wait as set in
slConnect should be at least 3 times as long as this
wait.
Returns zero if processed OK. Else, depending on ModChars and the global
return errors flag, will either display error and exit or will return
the error number.


My function:
Code:
SQLt_slOpen(rsFileName="", rsModChars="") {
   If Dll := SQLt_Init() {
      If rsFileName {
         If rsModChars {
            Result := DllCall(Dll . "\slOpen"
               , "UInt", &rsFileName
               , "UInt", &rsModChars
               , "Cdecl Int")
         } Else {
            Result := DllCall(Dll . "\slOpen"
               , "str", rsFileName
               , "Cdecl Int")
         }
      } Else {
         Result := DllCall(Dll . "\slOpen", "Cdecl Int")
      }
      ErrorLevel := SQLt_slGetErrorNumber()
      Result := (Result = 0)
   } Else Result := false
   Return Result
}


Calling it like this:
SQLt_slOpen("Example.db3", "C")

Throws the error:
Quote:
---------------------------
SQLitening
---------------------------
SQLite or SQLitening returned the following unexpected message!

-9 = File does not exist

Statement = Open "Example.db3
---------------------------
OK
---------------------------
(Not a typo; there is no closing quote in the error message and nothing listed after db3)

Like it doesn't see the "C" parameter for rsModChars. If I create the Example.db3 file beforehand, the function seems to work (no error at least) with or without the "C" as the rsModChars parameter. But then no other functions seem to work either.

I've tried changing between "Str" and using "Uint" and calling the vars with an &Var syntax, both have the same issue. I even tried adding the Cdecl ReturnType at the end of the functions which listed a return type in the help file for SQLitening, as you can see in my code above.

The SQLitening.dll file is written in PowerBasic. I also tried using the functions in SQLiteningVB.dll file (the same functions bridged to Visual Basic functions) but they didn't work (maybe to be expected?)

I'm going to keep trying to figure it out, but I don't know at this point if I'm going to be able to use the DLL with AHK.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 9th, 2009, 9:25 am 
Offline

Joined: February 5th, 2007, 12:19 pm
Posts: 192
Location: Osnabrück, Germany
Is there an advantage over using sqlite directly? There is also some nice work done with it in the forum.
Thanks for working on this!


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 9th, 2009, 6:54 pm 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
The main advantage seems to be ease of use and the fact that it works in both local and client/server mode, allowing it to act more like a standard database server if desired.

I don't have an immediate need for the extra functionality, but at this point it's more of just following through with the challenge of getting it working so I can give something possibly useful to the community :)

I suppose I could also work on my own implementations of SQL support in AHK based off of the existing SQLite work I've been looking into... but here's hoping I can find some sort of solution to my issue here.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 10th, 2009, 1:57 pm 
Offline

Joined: July 29th, 2005, 5:32 pm
Posts: 179
bmcclure wrote:
Calling it like this:
SQLt_slOpen("Example.db3", "C")

Throws the error:
...
Like it doesn't see the "C" parameter for rsModChars. If I create the Example.db3 file beforehand, the function seems to work (no error at least) with or without the "C" as the rsModChars parameter. But then no other functions seem to work either.
I just tried it, and it successfully created a new 0 byte Example.db3 for me as expected. Not quite sure why your getting that error :?:

Code:
SQLt_slOpen("Example.db3", "C")
#include SQLt.ahk

I'm testing it from XP at the moment..

EDIT: Forgot to mention that the function is returning true in both cases where .db3 already exists-- or doesn't exist.

_________________
.o0[ corey ]0o.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 10th, 2009, 9:06 pm 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
I forgot to mention I think, I've made some minor changes to the returned values from the function calls with SQLitening.

Sometimes SQLitening returns 0 if the command succeeded (as usually expected with that type of function) and other times it returns a value, meaning that 0 would be an error.

I've tried to standardize it so that the function always returns a true value if it succeeded (unless the returned result expected is 0 or false), and false (or 0) if it failed. In turn, I also set the ErrorNumber to the SQLitening error number of the last command called so that you can always tell if the function succeeded or failed.

In AHK I prefer functions that return true/false on success/failure so I can stick them in conditionals easier.

In the future when I get these functions working for me, and write my SQL helper functions, I may revert these back to their default behavior and just make the helper functions have return values like I prefer. This would probably be better for people who want a directly translated SQLitening library...

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject: same error here!
PostPosted: January 11th, 2009, 5:28 pm 
Quote:
---------------------------
SQLitening
---------------------------
SQLite or SQLitening returned the following unexpected message!

-9 = File does not exist

Statement = Open "Example.db3
---------------------------
OK
---------------------------


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: January 12th, 2009, 8:30 pm 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
That's the same problem I'm getting. Still trying to figure out why it won't work for me (or you) but worked fine for freakkk.

I'll provide further updates here as I figure the issue out.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: January 12th, 2009, 8:42 pm 
Quote:
but worked fine for freakkk.


No, he didn't call the sql_init() function.
That's why he didn't get the error.

Just remove sql_init() function call in your sample script

or copy and execute freakkk's code

Code:
SQLt_slOpen("Example.db3", "C")
#include SQLt.ahk


you'll get 0 byte db3 file.

But I'm sure it's not what you really want(just avoiding the error)


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: January 12th, 2009, 8:55 pm 
Offline

Joined: November 24th, 2007, 9:07 pm
Posts: 774
Oh you're right, I didn't catch that. Thanks :)

At least I know the problem is consistent now. However I'm still baffled at why it doesn't seem to be accepting the option in the second parameter with DllCall, no matter what I've tried to change in the actual DllCall.

I'll play around with this some more after work and see if I can get anything figured out. If anyone with more DllCall skills than me would like to take a look at my code and see if I may have missed something, I would greatly appreciate it. I believe I've tried all the various options and ways of calling it listed in the Documentation.

_________________
Ben

My Trac projects
My Wiki
[Broken] - My music


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 6th, 2009, 4:13 pm 
I'm not sure but your every function starts like below.
For example, SQLt_slOpen FUNCTION

Code:
SQLt_slOpen(rsFileName="", rsModChars="") {
   If Dll := SQLt_Init()   <--- RETURNED DLL IS NOT A FULL DLL FILEPATH!      

and your calling --> DllCall(Dll . "\slOpen", "Uint", &rsFileName ......)


Seeing your lib code, I am sure you are more skilled than me, but SQLt_init() is not returning what you want. How about check out the fuction and return value.
I hope this lib is done. I like it.


Report this post
Top
  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: IsNull and 19 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group