_SQLite_Exec problems

[jazzyjeff]

Hello,

I am trying something that I haven't done before and that's use SQL in a program. My goal with this project is to create a database for our computers as a standalone application.

When I try add information into a table it doesn't the data. I can tell me script is reading the information in my input boxes because I can output them into a Msgbox.

I think my SQL statement is wrong, but I'd be very grateful if someone can look at this code and tell me if there is something obvious missing. If it is easier to find the problem with all the code then please let me know.

Here is where the problem is though:

Case $btnAdd
$rSTUID = GUICtrlRead($inID)
_SQLite_Startup($sqlDLL)
_SQLite_Open($sqlDB)
_SQLite_Query(-1,'SELECT "Student ID" FROM Users WHERE "Student ID" = ' & $rSTUID,$sqlSTUID)
If $rSTUID = $sqlSTUID Then
MsgBox(0,"User Exists","The User ID is already in the system.")
Else
$rFirstName = GUICtrlRead($inFName)
$rLastName = GUICtrlRead($inLName)
$rUsername = GUICtrlRead($inUName)
$rGrade = GUICtrlRead($coGrade)
$rBuilding = GUICtrlRead($coBuilding)
$rAsset = GUICtrlRead($inAsset)
$rManufacturer = GUICtrlRead($coManufacturer)
$rModel = GUICtrlRead($coModel)
$rSerial = GUICtrlRead($inSerial)
MsgBox(0,"",$rSTUID & @CR & $rUsername & @CR & $rFirstName & @CR & $rLastName & @CR & $rGrade & @CR & $rBuilding & @CR & $rAsset & @CR & $rSerial & @CR & $rManufacturer & @CR & $rModel & @CR & @CR & "INSERT INTO users values (" & $rSTUID & "," & $rUsername & "," & $rFirstName & "," & $rLastName & "," & $rGrade & "," & $rBuilding & ");")
_SQLite_Exec(-1,"INSERT INTO users values (" & $rSTUID & "," & $rUsername & "," & $rFirstName & "," & $rLastName & "," & $rGrade & "," & $rBuilding & ");")
_SQLite_Exec(-1,"INSERT INTO computer values (" & $rAsset & "," & $rSerial & "," & $rManufacturer & "," & $rModel & ");")
_SQLite_Close()
_SQLite_Shutdown()
EndIf
MsgBox(0,"Successful","User added to the database")

[zorphnog]

You need to post more of your code. Specifically, the schema for your database (i.e. table creations). Also, you need to check for errors and return codes of your _SQLite_Exec calls.

[Zedna]

I think that problem are missing enclosing of strings to apostrophes in your INSERT.

Search this helpfile/forum for examples ...

Edited June 19, 2012 by Zedna

[jchd]

You're misusing _SQLite_Query: this function doesn't do what you think it does.

At any rate, I strongly advise you to use _SQLite_GetTable2d instead and test for error returns after invoking functions prone to failure (like I/O and DB access!).

Now, there are other things ready to go wrong: you read input boxes but don't escape the strings you insert. This can lead to errors or SQL injection attacks (Google that). Use _SQLite_FastEscape to keep away from those problems. Also it would probably be safer to validate the inputs given or you're likely to get a useless base in short time (e.g. manufacturer = HP, H.P., H. Packard, ...).

Finally you're doing a test for existence then a couple of inserts, all of which should be grouped inside a transaction. What if another program deletes the student you've found before you insert? What if computer already exists?

My advice would be to first model the DB as you need it by using a third-party SQLite manager (SQLite Expert is my all-time favorite for too many reasons to cite and it has a free, hassle-free version). Only when the design is settled, when every table is built consistantly alongside with other tables (foreign keys, triggers, constraints, ...), when every SQL operation is working in every aspect, THEN you can start coding your application. Else you're going to waste time and energy.

[zorphnog]

As @Zedna pointed out, use _SQLite_Escape for any string entries.

Something like:

_SQLite_Exec(-1,"INSERT INTO users values (" & $rSTUID & "," & _SQLite_Escape($rUsername) & "," & _SQLite_Escape($rFirstName) & _
    "," & _SQLite_Escape($rLastName) & "," & _SQLite_Escape($rGrade) & "," & _SQLite_Escape($rBuilding) & ");")

[jazzyjeff]

Thanks all for the quick responses. I don't think I am going to be able to report back with a success or failure anytime soon, as you've made me realise that this isn't something I am going to pick up in a few days. It's suddenly turning into a bigger project that I thought.

Thanks again.

[jchd]

That was my first impression. When you consider building a DB, you first need to clarify formally what entities you'll be dealing with, their semantics and specificities and, above all, the relationships they have with others. Only that will drive the basic design.

Whatever the engine you plan to use, SQL is essentially a tool for dealing with sets in the mathematical sense, which are called tables in SQL. Even the simplest design for some real-world problem easily needs a few to dozens of tables, while most complex can need thousands.

One role of the SQL engine is maintaining consistency inside and between tables at all times. That part is commonly done by using foreign keys, constraints, triggers, unique indices, transactions and sometimes needs cooperation of the application.

The other main role is giving efficient ways to manipulate data with insert, update, delete and obviously select statements. Typical selects may use several levels of sub-select and/or joining several tables.

Even with the little exposed in your first post and code excerpt, it seems you'd need a students table, eventually a grade table, a building table, an asset table, a manufacturer table, and so forth. But of course this only depends on the actual problem(s) at hand.

Many choices will be dictated by relationships one-to-one, one-to-many or many-to-many. SQL requires a specific way of thinking at times but proves very efficient in practice. Beginners often tend to group too much unrelated or redundant information into one or few tables, while more experienced designers create seemingly complex designs with many tables, and it turns out that the complex designs reveal much more efficient and easy than the compactified one.

Once all this dust is settled, the design will be much easier to understand, work with and maintain.

So yes, it clearly needs a significant thinking but once done the applicative part gets highly simplified, not having to worry about most consistency details. If you take an SQL-based project seriously, take the time to find good tutorials about SQL and study from there.

Download a good SQLite manager (reference above) and play with it until you get a better view of how SQL works.

[Zedna]

Good SQL tutorial is here

http://www.w3schools.com/sql/default.asp