Sephirangel wrote:
"Could not carry out the query because: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1"
It might help if you put a die($salesNoQ); after line #6 (going by your original post) and read what the SQL statement is. Then, cut and paste and feed into a MySQL command prompt to see what the error message was in perhaps more detail.
You'll want to start using backtick characters (`) on your `column` and `table names` because as time progresses and MySQL starts expanding its syntax, your favorite little table or column name may interfere with a MySQL command. I didn't do this for like six years and I had to start doing this after I migrated a project from MySQL 4 to 5 and had a nightmare of 60 pages to have to do this on, using the just-in-case approach to MySQL migration.
More advice:
* I'm a fan of adapted Hungarian syntax instead of variables like $itemCode. This helps me and other programmers later on to visualize what the main intent was for a variable. So I would be doing something like $sItemCode and $nQuant and $nPrice.
* I stopped using $_SESSION. It's harder to put into a web farm when you want to scale the app, and then you have the issue of session timeouts. Instead, I either store stuff in the database, accessed by a key I keep in a cookie, or I just use encrypted session and/or persistent cookies. If you haven't used the mcrypt_encrypt and mcrypt_decrypt API, consider it because it runs faster than you doing your own custom encryption with character mangling functions. You might need to add this mcrypt extension to your PHP, however.
* Put a space before and after the concat symbol (.). It makes it easier to read the logic.
* Use of mysql API is faster, but there's a few problems with it. Most of the active development these days is going into the PDO API, even though PDO is a little slower. However, that's all about to change with mysqlnd -- which will make PDO very fast. So I recommend avoiding mysql and mysqli API and going with PDO API.
* I give you an A+ for keeping the { on the same line as the declaration. I'm old school and that's how we did it back in the day. I see no reason to change. For me, it makes it easier to read the code that way.
* Don't know if that was a typo or what, but your closing } appears to be indented wrong, making it hard to visually realize it's mated to your for() statement.
* Consider 4 character width tabs, not 8.
* Instead of doing variable inserts into your SQL, consider using one of these approaches:
Strategy # 1. Don't use SQL directly. Use an ORM tool like Outlet ORM or Propel ORM. This helps you rip out code much faster.
Strategy # 2. Stick all your SQL statements in a central conf file. Store them as templated SQL with ^ or ? where the variables should go. Assign these constants to a variable when you need them, and then replace the ? or ^ symbols inside with a preg_replace statement (one iteration, not global replace) with your new variable. For a zippy fast conf file, just make it into a class variable with public variables storing the templated SQL statements.
Strategy # 3. Adapt Strategy # 2 but don't use preg_replace. Instead, use PDO's bindValue() API before running the SQL.
* Avoid spraying your SQL statements throughout the project, making it hard to fix a particular SQL statement without having to grep the entire project for similar SQL statements that might need the same or similar fix. One of the above 3 strategies will help you achieve that.
* I don't often see ProperCase type SQL column and table names. Most database designs I've seen used all lowercase table and column names, and then stuck the underscore (_) between words: sale_quantity, price_per_item. For me, when it's like 3am and I'm tired, it helps me separate variables from SQL statements when reading programming logic.
* You get an A+ for making your SQL statement syntax in UPPERCASE. This helps people see the logic a lot better and delineate it from the rest of the programming logic.