found a new Sqlite wrapper & function

[Paul J Newcum]

Hi, I found a new Sqlite wrapper & function for my PowerBasic Win database project called:

"SQLitePlus is a COM Wrapper DLL and Database Manager"

It provides a COM .DLL wrapper and also a Sqlite add-on, and includes the familiar small footprint Sqlite engine inside this product's wrapper (Sqlite itself is already inside this particular add-on product).

It's single developer affordable license of $100 and its add-on functions were enough to convince me to acquire it for my PB Win project.

The product's description and features are at: http://www.sqliteplus.com/

Hope this can help others, as it took me days to search out the various database options, then select the one that best fits my PB Win project.

[Mark Strickland]

Another Option

You might have wanted to look at the work by Paul Squires for his Client Server SQLite project. It is still very much in BETA but it does work nicely.

SQLite itself is not truly multi-user. Paul's project solves that problem. It also makes SELECTing and processing record sets pretty easy.

Take a look on his site for the code and more details:

https://www.PlanetSquires.com

Navigate to the FORUMS and look for SQLite.

[Paul Squires]

Paul,

If you are using PowerBasic for your project then why would you want to use a COM wrapper over the SQLite DLL? That doesn't seem right to me. You can easily call and use the SQLite3 DLL directly without the burden and complexity of dealing with a (costly?) wrapper. I don't mean to lessen your excitement, but I don't understand the need for the COM wrapper - can you elaborate why you want the COM overhead?

[Paul Squires]

...add-on functions were enough to convince me to acquire it for my PB Win project.

Ah, I skipped over that part. The wrapper must have functions that are not easily reproduced in pure PB code. I will check out the site you mentioned.

Also, I noticed your question on the SQLite mailing list. Placing the DLL in a shared path is an easy solution. The only issue that could arise is if your application depends on a certain version of the SQLite DLL. In those cases, because the footprint of the DLL is so small, it is just as easy to put the DLL in the same directory as your application (and that's the first place Windows looks at anyway). From an application maintenance standpoint, putting the DLL in the same directory as your application makes it easy to install/uninstall and update.

Thanks,

[Cliff Nichols]

From an application maintenance standpoint, putting the DLL in the same directory as your application makes it easy to install/uninstall and update.

Not in all cases......don't forget what VISTA up and changed.

On the other side, this is what I have always done with my DLL's written in PB because I can avoid "DLL-Hell" and know where the DLL actually resides on a users computer when I can not see that computer, and the user has no clue where they put it.

[Joe Byrne]

Not in all cases......don't forget what VISTA up and changed

I'm not aware of any change in Vista regarding the placement of DLLs in the program folder. I know you can't (shouldn't) put writable files there (such as INI files, etc), but I believe a DLL is fine and that is still where Windows Vista looks first.

I'd be happy to be corrected if I'm wrong.

[Paul Squires]

Joe,

I think you are correct - at least, that's how I understand it as well.

[Shawn Anderson]

SQLite itself is not truly multi-user.

I've heard this before... can you point me to some documentation on that?
Thanks!

[Chris Holbrook]

I've heard this before... can you point me to some documentation on that?

A lot of sources on the www relate to earlier versions of SQLite For SQLite 3, see: http://www.sqlite.org/lockingv3.html

[Shawn Anderson]

thanks Chris