Jumpy09

You are welcome, I figure if I find out the answer it is only right to post the solution for other people. Technically I caused my own problem, but glad I remembered what potentially caused it. Another thing is: If you actually have this problem, dumping an SQL File and swapping the lower_case_table_names to 1, delete the tables, then execute the sql file... this will store the table names as lower case. Just remember to swap all the queries to lowercase in this situation, just as a precaution. This will swap all the Foreign Keys to the lower case, the tables to the lower case, and everything works then. No need to remove Foreign Keys, especially if you made the booboo of disabling Foreign Key checks instead of resolving the originating problem like I did lol.

Alright to answer this question in case someone happens to run across this problem. When utilizing Windows and wanting to utilize Case-Sensitivity for Cross Windows/Linux Support... utilizing Lower_Case_Table_Names = 0 will only help move the casing of the table names properly over to Linux. Linux is a case-sensitive operating system so the table "accounts" is much different than "Accounts", where as in windows they are exactly the same thing. Unfortunately where you can properly access your tables between both Windows and Linux with Case-Sensitivity, Foreign Keys seem to only work with what InnoDB was originally intended to do, which was to store all table names in the lowercase to aid in smooth transition between Linux and Windows. I had a problem swapping Foreign Keys from Windows to Linux before due to the fact the Foreign Keys were trying to access the table names differently, so I thought I fixed this by swapping lower_case_table_names to 0 because I like to utilize Upper_Cased table names because I thought it looked nicer and cleaner. Unfortunately everyone is just better off sticking to lower case table names regardless due to this if you are utilizing Foreign Keys. I have not had any problem moving between Windows and Linux without Foreign Keys and I have always ended up keeping the correct casing on the table names. However the Foreign Key portion of InnoDB doesn't like it very much... so just save yourself the trouble and always stick to lowercase table names. I know most programmers already do this, but for people like me who want to make crap complicated.... hope this finds you well. Note -- When I mean I was having issues swapping over, it was because Windows was spitting out the table names in lowercase and everything was set up for case-sensitivity. I can't remember the specific problem or why I changed the lower_case_table_names to 0, all I know is I thought I fixed a problem. Now I couldn't create or use Foreign Keys without it causing a nightmare. So lesson learned, sticking with lower_case table names . Thank you to everyone who attempted to answer this question or at least checked it out. I had a feeling it had to do with the lowercase issue, which is why I included it. Good luck in your programming career!

This is just starting to bother me, when does a table exist... but not exist? I am utilizing Navicat for Database Administration and it makes adding Foreign Keys.. as simple as selecting from a drop down list. So these tables do exist and their fields do exist... however I am getting this error! Foreign key constraint fails for table `MyDB`.`My_Table`: blahblahblah But the parent table `MyDB`.`My_Table_2` or its .idb file does not currently exist! I am using XXAMP 1.7.* which has not been a problem for me in a very long time. I had a problem in the past where Windows wouldn't keep uppercasing of Table Names or Rows properly so my Foreign Keys would fail on a Linux Set-Up. So I modified the "lower_case_table_names" to 0 which keeps the original table names. All look-ups have always been in the correct casing, but I am starting to wonder if this may end up messing with my Foreign Keys. They keep failing, but if mysql is storing them with the proper casing... why would the look-up be failing? Any suggestions? P.S. Keep in mind that Navicat gives me a list of tables to select from, all of which do actually exist. I have not tried this on a Linux Set-Up as I only have access to the XXAMP Windows Set-Up during Development. It is so much easier to locally edit files than have the middle man of making sure they are updated before testing. No the table names and the db names in the error code are not real. I am writing this from my Laptop and couldn't copy the actual error message from my Desktop. I will continue looking for problems. Thanks!

Verified my problem. lower_case_table_names forced to 0 on a Windows Server does throw problems with Foreign Key Constraints. The Table Names used in the Foreign Keys are lowercased when lower_case_table_names set to 0 makes it case specific. Since lowercase table names wouldn't match up with MiXeDcAsE Table Names, the Foreign Key Constraint Fails. I verified this by trying to add in a new record in a Table which received it's Foreign Key from the Import. If you also work on a Development Server that is on a Windows Operating System and you have forced lower_case_table_names to 0 to keep your Table Names. I advice also running this on the Windows Server. SET FOREIGN_KEY_CHECKS=0; I would also only add Foreign Keys on a Linux Server to make sure if you have Case Specific Table Names, that the Foreign Keys will match up properly. If you upload from Windows to Linux and you have forced lower_case_table_names to 0 on Windows, ensure you set the Foreign Key Checks back to 1, this should automatically happen if you turn off Foreign Key Checks in the SQL Export Dump. If you force lower_case_table_names to 1 on Linux, then you shouldn't have any problems. Currently until MySQL integrates FULL Foreign Key Support into MySQL, this will be an issue. Thank you for all the assistance, kind of sad that you have to force Linux to work with Windows, but there isn't a full way to make Windows work with Linux. Oh well, problem solved.

After some more investigation it appears as if the InnoDB Foreign Key Parser is separate from MySQL itself. So if MySQL is forced to being Case Sensitive on a Windows Platform, the Foreign Key portion may be still set as lowercase when getting added, which I suppose would throw the error. It seems I will just have to wait until I am completely done and just add the Foreign Keys on the Production Server and then Export it afterwards if I need to further work on it on the Development Server.

A) The Parent Table Columns are all Primary Keys, Indexes would automatically be added to the Child Table if not set before hand. I have set indexes on the Child Table for testing, but to no Avail. B) Both Parent Table Column and Child Table Column Flags are identical. If Unsigned, both are Unsigned. I do not use Binary. C) The Data Types between the Parent Table Column and the Child Table Column are Identical. The two I am attempting to set up are AID and CID - AID is varchar(36) and CID is int(11) Unsigned. I have checked for all three of those potential issues, but everything is Identical. As I mentioned I have forced lower_case_table_names to 0 on my Windows Development Server because I want Uppercase Letters in my Table Names. When working on the Development Server this didn't want to comply, so when calling the Tables on the Linux Production Server nothing worked. I could either keep lower_case_table_names forced to 0 on the Windows Development Server or Replace the Table Names in the SQL Export, which I opted for the easy solution. Unless lower_case_table_names forced to 0 on the Windows Development Server is the issue, I do not know what else could be. Indexes add just fine, but Foreign Keys will not. The Tables on the Windows Development Server are uppercase where they should be in regards to the .frm files. In the ALTER TABLE Syntax the Table Names are also Uppercase where they should be. With Data in the Database, the Child Table Columns match up to Primary Keys in the Parent Table Columns. The int(11) Primary Keys are Auto-Incrementing so they have to have the Primary Key Index. I see absolutely no reason why these Foreign Keys shouldn't be submitted, I will try in a bit to add one on the Production Server to see if it is just the Windows Development Server. UPDATE::: I just successfully added the Primary Key to the Production Server which has the exact same Database as the Development Server. I am beginning to think that it is due to the lower_case_table_names forced to 0. If set to 1 or 2 the Table Names are not stored right which causes issued for the Production Server because windows stores everything lowercase. I am calling all the Tables and Everything with the proper cases and do not mix casing in any situation. I wanted to use uppercase letters to make it neater and swapping to lowercase would result in editing every query to work right on Linux. Can anyone comment on whether forcing lower_case_table_names to 0 can cause problems with adding Foreign Keys?

I have previously added Foreign Keys, this was before uploading it to the Production Server and then Exporting it to upload back to the Development Server. I thought maybe it was because the data wasn't lining up properly, so I Truncated all of the tables and then tried to add them back again. I can't get them to add on anything, going back and trying from the beginning isn't really an option at this moment as I am still developing on the project itself. I had intended on adding the rest of the Foreign Keys once I was completely done with the Database, the Client needed something to get an Adsense Account, so I uploaded what I had. Since the Client created an Account, I didn't want to upload a from scratch Database, so I just dumped it into an sql file and uploaded it onto my Development Server. Since then I am unable to add Foreign Keys. There isn't a mix-up of information as I Truncated and despite the difference between data types I can't get any Foreign Key to be added. All Int Data Types are Unsigned, and all of the Varchar Fields have the exact length, char sets, collations, and none of them are Binary. I posted this because I was wasting ample Development Time trying to find a resolution. I am sure if I started from a clean database and added all the tables back up manually, then the Foreign Keys would stick. I do not really have that time as a luxury right now, so I was wondering if something happened in the process of Dumping the Table and then Importing it into a different Server would cause this effect. I dumped out of PHPMyAdmin and Imported via Navicat MySQL Premium. I enabled skipping the Foreign Key Check as Importing has caused issues for me before. I had considered that something was wrong with the FOREIGN_KEY_CHECK, but even set to 0 the Foreign Keys from the SQL File were added on Import. It is just after it is successfully Imported that I cannot add any new Foreign Keys. I have tried this on several different Parent / Child relationships to no avail. Unless I can come up with a reason as to why it allowed me to add Foreign Keys on the Original Development Set-Up and not the Imported Development Set-Up, I am just going to have to skip Foreign Keys for this job. I've double, triple and quadruple checked the Fields, the Data Types, the Engines, the Character Sets, the Collations and anything else that could potentially cause the issue. As I said there are Foreign Keys in the database from when I originally created the table. The problem didn't start until I exported and imported the database. EDIT::: Production Server is Linux Development Server is Windows I forced lower_case_table_names = 0 on my Development Server so that I could keep the Upper Case Table Names as it was required to be set. If lower_case_table_names is set to 0 which turns on Case Sensitivity, could that potentially be a problem? Navicat will Export the Development Server SQL with the proper case in the Table Names, so I would figure that it would be adding everything in terms of Foreign Keys properly.

Alright I tried to set up Foreign Keys on a Database with data in it, but I decided that maybe it was failing because I had data stored already. Now this isn't the case as I truncated all the tables and Foreign Keys still fail to be inserted. I am getting the 1005 - Can't create table "" ( errno: 105 ) What I know: Table Engine: InnoDB Table Character Set: utf8 - UTF-8 UNICODE Table Collation: utf8-unicode-ci Table Row Format: COMPACT Primary Keys: Set Primary Key Types: INT / VARCHAR Field Data Types: Exactly Identical for Primary Key of Parent Table and Foreign Key of Child Table Note: I have verified this Information over and over. I am 100% positive there are no MyISAM Tables and all the information is 100% Accurate. I am open to suggestions, but this is a bit aggravating. Additional Information: I dumped the Database from PHPMyAdmin on a Publication Server and Executed the SQL Script through Navicat on my Development Server. In the Script contained SET FOREIGN_KEY_CHECKS=0; at the top and SET FOREIGN_KEY_CHECKS=1; at the bottom. I cannot figure out why I cannot add any Foreign Keys to the Tables and it doesn't matter what I am trying to add, it pops up with that error. The MySQL User has Super Admin Privileges, so I do not think it is that. Any suggestions?

Decided to just change how I had it set up. I have an idea of what the actual problem is, but just changing how everything is set up seems more suited than trying to resolve this issue on my Development set-up.

Alright so I have successfully set up a Mod Rewrite that gives clean URLS to everything on the normal scope. This deals with files located in the root directory, but the way I am doing admin pages I am having a bit of a problem getting the rewrite to work right with it. Alright so I call the admin page through http://127.0.0.1/admin/ I want this URL to go to http://127.0.0.1/admin.php which will call files from within the directory of /Admin/ This is what I have in regards to that. RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^admin/$ admin.php From what I understand this should rewrite even if the directory exists, but since I have -Indexes I am receiving a 403 Error ( Access Forbidden ) and if I have +Indexes I get the Admin folder. Is there anything I am missing? This is done on an XAMPP 1.7.7 Setup Apache 2.2.21 ( Win32 ) PHP 5.3.8 Edit: The only thing I can think of is to place a .htaccess file in the directory, but shouldn't the main .htaccess file catch the request even before it gets that far? Edit #2: For my local server I am working in a Sub-Folder so technically it is http://127.0.0.1/Site/admin/ and the rewrite base is /Site. The .htaccess file is located in the /Site/ sub-folder. That slipped my mind. I moved the .htaccess file to the Root Directory but I think I would have to rewrite the rewrite items to make it even rewrite correctly.

No I do not have an empty in it because anything that would be empty would resolve to be false in the ctype_digit anyway. The function primarily works like <?php if ( ctype_digit ( ( string ) $input ) ) { return TRUE ; } else { return FALSE ; } ?> The only difference is before the True or False it puts a message into the session to spit out to the user. I do know that empty will find 0, even if it was a string, to be empty, but I require 0 for other portions of the application so it was not something I implemented into the Data_Validator. I am running PHP 5, I do not know the exact version but I did however find those bugs on my initial search. https://bugs.php.net/bug.php?id=34645 specifically is what I thought was happening, but the value is still echoed out afterwards. I was really hoping I was just dyslexic with the $_POST [ "x_trans_id" ] and posted something like $_POST [ "x_trnas_id" ], which would make me feel better. This thing has been agitating me all day long and I am quite fed up with it. I think I am going to take a nap and come back at this tomorrow. Thank you all for your help and I apologize for getting agitated.

Sorry for my hostility, but the Data_Validation function was coded months ago and has yet been a problem anywhere I have utilized it. Since no one has been able to find an error with the code I posted let's try this again. I just ran another test and split the isset and the Data_Validation and received: x_trans_id isset and equals 0 Purchase Process ( Line Number: 129 ): Transaction ID is not a Digit! -- 0! So it is definitely the ctype_digit which is failing. Yes I am absolutely 100% sure it isn't the function that I set up that is failing. The Input going to it is not being validated as a digit, even though 0 is suppose to be validated as a digit. Yes the $_POST [ "x_trans_id" ] is type cast to ( string ) even though it comes already assembled as a string before going through ctype_digit ( ). I am going to test something else and then I will be absolutely certain that "0" isn't being validated as a string.

Let me point out something: Functions :: Data_Validation ( $_POST [ "x_trans_id" ] , 3 ) === TRUE Functions :: Data_Validation is basically ctype_digit with error messaging to be displayed out in a Message display system. It isn't intended for debugging, only to give an indication to the user what is wrong. var_dump the ctype all you want it is suppose to spit out TRUE or FALSE, which is why that portion is coded into the script. ctype_digit doesn't change the input you spit to it, just checks to see if it is a digit. ctype_digit also expects the input to be a string, which I have type casted all input to ctype_digit to ( string ). No that isn't a correct assumption, you are attempting to find a flaw with something I already have knowledge of and expect the outcome of ctype_digit to be a bool. No, unless there is an issue with the code I have provided then there isn't a problem with my code and may be an issue as I have mentioned in the Original Post. Correct the $_POST [ "input" ] is always going to be a string because HTML Submitted Input will always be a string. Also ctype_digit is a validation method to check to see whether or not the "string" being submitted to it is comprised of digits. As per the PHP Manual, the result of ctype_digit will be True or False. http://php.net/manual/en/function.ctype-digit.php, I have not implemented this function incorrectly. Cast to boolean? The code to Functions :: Data_Validation() has been working for the last 2 months across the entire application without any similar result. It is not a concern and when used with anything else except for this one particular posted value, it works as it should. Now since there isn't a easy fix that can be spotted in the code I posted, because it is the only portion of the entire application that isn't working as it should, could we start pointing out reasons as to why ctype_digit wouldn't validate ( result in TRUE ) a string(1) "0" that is posted from an outside source. If we want, I am using an Authorize.net Test Account to set up an Authorize.net payment system. The site posts to Authorize.net using the SIM ( Server Integration Method ) as it should to the Authorize.net Payment Form, I fill out a bunch of information and hit submit. The transaction is successful, but because I have it set on Test Mode the x_trans_id sends back 0. It sends back 0 because there is no Transaction actually taking place, and I had considered that maybe somehow the $_POST [ "x_trans_id" ] was submitting back a different type besides a string. In the DIE, notice the error message I posted the 0 is actually displayed, I did a var_dump of the $_POST [ "x_trans_id" ] and it echo'd out string(1) "0". I've tried ctype_digit and ctype_alnum and both of them both resulted in the else ( the die ). The Functions :: Data_Validation ( $input , 3 ) validates a ton of shit across the entire application that is completely functional after a very thorough Alpha Test, so I know for a damn fact it isn't that function. I know when dealing with problems a ton of the time there is a solution that is very easily spotted. I've taken the Functions :: Data_Validation ( ) out and replaced it directly with ctype_digit and it still resulted in the same result. Any other suggestions? I do appreciate everyone's help, but a little less thinking I am brand new at this would be very much appreciated. As I said I have gone over this several times, I cannot recreate it and it only occurs with x_trans_id, which from the DIE in the ELSE it still spits out the value of x_trans_id so I do know that it is in fact set.

So were you right? If not, since I would be the house.. how much money have I won?

Obviously if it is spitting out the error it is a typo that has seemed to have followed me from it's conception. I tend to copy and paste a lot as to not deal with errors later on, but in this case the copying and pasting has saved me the typo from being a problem. A simple fix, but still not a resolution to this problem.

You are thinking I have an error in my code, because 99.9% of all errors are generated from a typo. I've been over my code 100 times and I can assure you that there isn't any error. The $_POST [ "this" ] is typed in right, verified by it actually spitting out the value in the else of the if. The format of that section is the exact same, copy and paste, of another section which is directly above it and the one above it works. I am using Notepad++ and all of the syntax highlighting is correct, php isn't spitting out any errors for parsing errors. There is absolutely no mysql involved at this point so that is out of the question. But if you want it, I've tried to recreate it using the exact same "copy and paste" changing the class / function out for ctype_digit itself, but I cannot recreate the problem. <?php if ( isset ( $_POST [ "x_trans_id" ] ) && Functions :: Data_Validation ( $_POST [ "x_trans_id" ] , 3 ) === TRUE ) { self :: $_CLEAN [ "TransactionID" ] = $_POST [ "x_trans_id" ] ; } else { if ( _ERROR_VERBROSE_ === 1 ) { die ( "Purchase Process ( Line Number: " . __LINE__ . " ): Transaction ID is Invalid! -- {$_POST [ "x_trans_id" ]}!" ) ; } else { return FALSE ; } } ?> Prove me wrong though I would love an end to finally come of this stupid error. As an added bonus I will even give you the error it generated in the else! Purchase Process ( Line Number: 121 ): Transaction ID is Invalid! -- 0! See the 0? I see it, it's so pretty sitting at the end of that error... but the Data_Validations function in the Functions class ( 3 ) is ctype_digit and it works everywhere else in the entire application, except for this one location. Anything at this point towards a resolution would be awesome.

What types of occasions would ctype_digit not validate a string(1) "0"? My script is getting a posted variable from an outside source which is string(1) "0" and while it is set, it chooses not to validate. The field names are correct, the $_POST is written correct. There are no spelling mistakes or errors in the script, but I cannot get the ctype to validate using either ctype_digit or ctype_alnum. When would a posted value not be resolved to TRUE using ctype_digit or ctype_alnum? Edit: The last question revolves around the posted value being a string with the value of 0. Edit 2: For argument's sake let's say I have the brand newest of new PHP Version, there is no errors in the script, and what I am posting is actually occurring. I am checking that it isset and that ctype_digit === true, this works with everything else and still for some BS reason it won't validate this one posted variable. Let's also say that the chances of you recreating it are likely 0, so even if I posted the actual code it wouldn't really help anyway.

Alright so I have this: var tabindex = $("ul#myid").index("li > a.current"); The problem is it isn't quite working the way I want it to. Edit: I do see the problem with this, but I'm still not quite sure how to do what I am aiming for. I know you would do something like $("#myid li").index("#listid");, so I'm still not entirely sure how to get what I want. Take the following code as an example: <ul id="myid"> <li><a href="#blah1">My Link #1</a></li> <li><a href="#blah1">My Link #1</a></li> <li><a href="#blah1" class="current">My Link #1</a></li> <li><a href="#blah1">My Link #1</a></li> <ul> Basically I need to pull the index of the <li> which contains the <a> that has the current class. Basically index need to return 2, but either returns 0 or -1. I am testing it where the current class is on the 3rd to 5th link, so 0 or -1 isn't really an option of what it should spit out. I figure it is because the <a> is in the <li> which would result in 0 to be the index. The issue is I cannot place "current" on the <li>, which of course makes things a bit dumb. From what I thought is it would use the <ul> as a primary parent, then select the <li> of the <a> that contains the current class. Everything in my mind states this is right, or at least should be right.. but obviously it isn't. Any assistance would be greatly appreciated. P.S. I have done some preliminary Googling to find an answer, but I'm kind of on a tight deadline and don't have hours to spend debugging this. I figure it is a rather simple solution, but so far the results from Google have not landed me in the right place to get the answer I need. Kindest Regards, Jumpy09

API or Library Files would work on the same principal that if you update 1, the other is updated. No need for redundancy or duplicate files spread all over the server. You still have to create separate files for the API Utilization through each of the "Guest Sites", so any changes to the Original System would still require updating code in the "Guest Site" API Files found in the Main Site / Application. For Data which the Sole Intent is for Display Purposes only and not for Authentication, Validation, or relied on to determine what a script will be doing can be sent in HTML or XML over HTTP / HTTPS Protocols through either JSON or AJAX without really serious Security Risks. I would always use HTTPS to transfer any Data from point to point to prevent Eavesdropping / Man In The Middle. If you want to set up the Account Authentication, Validation, Verification, and all that as a Web Service I am really interested in what Security Implementations you would be developing to maintain Authenticated Session Control between the Account Web Service and all the Processes / Actions found on the Site that requires a valid Log-In / Session to perform. Will you be allowing the Same Sessions across both sites, or will each Session Management be separated? Direct Access gives you Optimum Security if you set it up right, I can only imagine how any shotgun shells / machine gun drums that you will be unloading or blowing through your Website's Security by utilizing an Account Web Service.

If the websites are on the same machine and running under the same instances of PHP / Apache / MySQL then you could go another route all together. Under the assumption that the websites would be run in coherence with one another as if you placed 3 websites in a single Shared Hosting Environment, instead of each in their own Shared Hosted Environment, the websites could communicate with each others databases directly through php or whichever programming language you are using. For example since they would be located on the same machine using localhost for all Database Calls would be allotted as they are all hosted under the same localhost. Foo.com accessing the Database using 127.0.0.1 or localhost would access the same Database as Bar.com using 127.0.0.1 or localhost. You would only need to access the specific databases to pull the information from them to display on each of the websites. If they are on the same machine / localhost, you have three options as to how you go about setting up the Database. #1: One Connection / One Database for both sites to utilize together coherently. #2: One Connection / Three Databases for each specific purpose / site. #3: Three Connections / One Database per Each Connection, granting the Foo.com, the Bar.com, and the Linked Accounts each their own Connection. #2 and #3 I would suggest using a unique Username / Pass for the Connection to mitigate any totalitarian access in the horrible event someone was able to maliciously gain access to one of the Usernames and Passwords. This would protect each individual Database to mitigate potential catastrophic effects from the exploitation of 1 site. Just use multiple connections to access the specific portions you need, which will run everything under a single Apache process to help with your Performance concerns. Of course if you are aiming to separate the sites in a method that each would run from a separate Shared Hosting Platform, then this method would not quite work out very well. I know you can give cPanel Accounts Dedicated IP Addresses / their own specific IP Address, but I'm unsure if this is possible on a closed loop manner as well. For instance 192.168.1.115 is inaccessible from the Internet, so if you could give each site its own Local IP Address instead of a Global one, then it would be possible to use the same methodology behind the scenes in the situation that each website had its own closed / jailed set-up. Sorry if my wording is off and this is under the assumption that PHP is run as an Apache Module or you are running all of the sites in the same htdocs folder. If you plan to expand to allow remote websites to also access the Database which would not be located on the Server / Machine hosting the databases, then this would not really work out very well. Hopefully I made the right assumption and if so, there would be no reason to treat each website like they are on separate machines unless your Long Term Plan is to eventually have them on separate machines. If you are going separate machines, AJAX actually isn't a bad method which uses Javascript and Server Side Programming together. Make sure you have a nice hash value per user that changes each time a user logs-in and send it ( hopefully over HTTPS ) to the Server in Question it utilizes everything on that machine and sends you back whatever you need it to in order to provide functionality. Good part about AJAX is that you can move one site to any server in the world and the functionality will always work without doing a lot of back end setup. I've never personally used CAS. but it does look somewhat promising. Downside of AJAX is you open the particular file open to be directly accessed, so you would need to set up enough security to ensure only legit / valid users are able to access the processes within the files. AJAX does somewhat increase bandwidth usage where as hosting all the sites / databases on a single server wouldn't. Hopefully this is helpful.

Prepared statements were intended for when you need to repeat queries, such as inserting a list of cities in a database or pulling out a list of items based on different parameters. Through serendipity I assume, the fact of sending the Query and the Parameters separately also provided a work around to prevent SQL Injection. From what I figure the Prepared Statement ( The Query ) is sent first and then the parameters are sent. Since the query went first, MySQL now knows what to do with the Parameters. So you do : <?php $books = array ( "Blah1" , "Blah2" , "Blah3" ) ; $authors = array ( "Dr. Blah" , "Dr. Blaaaah" , "Dr. Bllllaaaahhhhh" ) ; $parameters = array ( ) ; foreach ( $books as $b ) { $parameters [ $b ] [ "Book" ] = $books [ $b ] ; $parameters [ $b ] [ "Author" ] = $authors [ $b ] ; } $query = $my_mysqli->prepare("INSERT INTO zend_dwoo_books_author (author, book) VALUES (?, ?)"); foreach ( $parameters as $p ) { $query->bind_param('ss', $parameters [ $p ] [ "Author" ] , $parameters [ $p ] [ "Book" ] ); $query->execute(); } ?> I'm not sure how much in optimization it would do for such a small amount of loops, but when you get to thousands of loops you can save some overhead time using prepared statements. Of course if you use multiple-rows insert syntax you are only sending 1 Insert Query so it does run much quicker. Since the Author and the Book are sent separately from the statement itself any single quotes or any other special characters won't have an effect on the query itself. In a Top Secret world think about multiple Carriers being sent out with different pieces to the bigger puzzle. If a single Carrier was to become compromised it wouldn't have any effect on the Grand Scheme. Thinking about this in a Job Environment, the prepared statement would be your Boss telling you to do something a certain way. Now that you know which way to do it, you don't have to be told to do it again and anytime it comes up you know exactly how to do it without instruction. The functionality was included in MySQL 4.1 and Above, but the old MySQL Extension didn't cover Prepared Statements, so the MySQLi Extension was created to allow it. I do believe the fact it prevented SQL Injection was a nice bonus because of what it was originally implemented to do, but some people typically suggest to always use Prepared Statements for both Optimization and Security. I think Optimization and Security can be equally obtained in normal statements as well as prepared statements, but then it just comes down to personal preference. If I am wrong in my understanding, someone can correct me if needed. I do believe that I have the basic concept, but I'm not quite 100% sure how to explain .. so sorry for my analogies if they don't quite make sense. Now I am not arguing which extension is best, both have their ups and downs.

Alright, despite my Moral Objections, I will post some potentials for Source Code Encoding / Encryption. There are ways of decoding / decrypting the source code to obtain it, but it can sometimes get expensive for someone to go through another company to do it. As long as the Licensing Provision included a statement that claims the Customer cannot decode / decrypt the source code or they would be violating the Terms of Use, you would have legal grounds to sue if your company somehow finds out. I feel most companies won't be looking to circumvent your system, but if there is a few rouge companies be sure to let the guys upstairs know it happens to be all you can really do with PHP to protect the system. If someone circumvents it, they should be aware that they could lose money on the per seat license style as there would be no way to know for sure. You would also be risking that a rogue employee would take the source, decode / decrypt it, and release it publicly. Potentials for Code Encoding / Encryption: http://www.sourceguardian.com/ http://www.codelock.co.nz/ http://www.ioncube.com/sa_encoder.php http://www.zend.com/en/products/guard/ From what I can figure Zend Guard and Ion Cube's PHP Encoder are the Encoding / Encryption Services most frequently used, however here are some links to decoding / decrypting both Zend Guard and Ion Cube's PHP Encoder. http://www.showmycode.com/ :: Claims they can decode Zend Guard ( Have not tested it ) http://zendecode.com/ :: Obvious from it's name ( Have not tested it ) http://forums.zend.com/viewtopic.php?f=57&t=2242 :: A statement by a Director of Product Management for Zend Guard related to Obfuscation Programs. http://www.unzend.com/ :: Supposedly decrypts IonCube and a bunch of other types of encoding. Obfuscation / Encoding only inconveniences your legitimate, law-abiding customers, while the people who would would rip you off are not your target paying customers anyway. I'm not trying to say that Per Seat isn't acceptable, in many cases it is, but in this particular case it becomes an Arbitrary Limitation. I know you may not be in a situation to convince the Boss that the Product Model is wrong, but any system to try to protect the Per Seat Licensing Model will just impose annoyances on your customers. If they just altered the License Structure to suit per server then the Boss would make more money, the customers won't be annoyed, and you won't have to worry if someone has decoded your encoding to circumvent anything. In all of my time spent on the Internet, which is more than I care to admit, I have never seen a PHP Application run on a Per Seat Licensing Model which the Customer obtains a copy to. Now why would that be? I am arguing the Per Seat Licensing because this is imposing serious annoyances and inconveniences on the company you work for, which both the KISS Principal and the how everyone on Earth works besides Humans, take the Path of Least Resistance! A simple change to the Licensing Model / Pricing Structure will defeat everything else, make everyone much happier, it is the Path of Least Resistance. For some reason humans are hard wired to defy nature and do everything in the most complex and complicated ways. Negate the Moral Objection, now we are just talking what is the most Logical Solution to a problem that you can either jump through hoops and still have short falls, or change a bit to cover all your bases? Either way I have given you examples of encoding / encryption systems, so you have alternatives. I'm not sure if the Company will pay for the Encoding System or if you will, but if you take it to the Boss at least pitch the Path of Least Resistance!

Technically with the "API" the Database containing the Users, and the Application that performs various functions would be hosted on YOUR server. The only thing that the Client's Website does is request an embedded impression of only the Output the Application spits out. Taking Javascript / PHP AJAX Calls the JS Script would send a request to your server, this would be exactly identical to a visitor stumbling upon that script and accessing it directly. Your script verifies the API Key and sends output on whatever action or process would be taking place. Let us take Log-Ins for example: 1. Visitor lands on the Client's Website, the Client's AJAX Script sends a request from the Visitor's Computer to your Server with the Client's API Key and an action, let's call this action getlogin. So the AJAX calls let's say http://www.yoursite.com/application.php?apikey=blahbah&action=login. 2. The server submits the login page and then it is sent back to the Visitor to be dealt with in their browser. Javascript writes the content obtained from your server into the Client's Website from the Visitor's Browser, the Client's API Call never technically touches your Server. So now the Log-In Page is displayed with all the appropriate actions, methods, and form input fields. 3. The Client then fills out the Form and clicks submit, which then sends the POST Request BACK to YOUR SERVER to validate the Log-In. If the Log-In is valid the Server will send content back to the Visitor allowing them to proceed to utilize the Application. As I said the Client / Your Customer never obtains a copy of the Application so they cannot alter the user limitation you have placed. Since it requires Bandwidth Consumption / Server Usage, selling the Application in this fashion with User Limitations is Morally Acceptable. Selling an Application to someone when they obtain a copy of it with a user limitation is just a Milking Scheme, trying to milk more money off of a customer. This can also be done with iFrames to reduce the scripting of the Javascript Scripts featuring the AJAX Calls to YOUR SERVER, I still don't quite understand why you think they can still circumvent the User Limitations in this method. From what I figure your Database would hold the Users in a Table and the Companies with a License in another table. The Company Table would be tied to the Users Table in a One to Many relationship where you can count the number of users a Company has to restrict or prevent more users from joining. API gives your company full control over the Source Code that prevents other people from making modifications and also gives Moral Grounds for charging on a per user basis. You would also be able to charge on a monthly basis, granted the price was configured in a method to allow Companies to afford more users without forking over their entire profit margin for that month. Any other method and you should be looking to alter the method in which the Application is licensed. I personally suggest if you want to hand over a copy, remove the arbitrary user restriction and sell the licenses in some other format to generate a similar revenue. Either suggestion would eliminate the need to try to stick it to your customers, which I don't personally feel is a good Business Model to be using. Just my two cents, hopefully you are able to grasp the concept I am trying to portray when I say "API". Application Programming Interface: Think about it this way, when you access a website you are only obtaining the Visual Representation of what the Server Side Scripting is doing. The API works in a Similar Manner, your Customer will only be able to display a Visual Representation of your Application on their website ONLY when an End-User accesses the particular webpage on the Customer's Server. The Application / Program / Database / Functions / Schema / "" EVERYTHING "" pertaining to your Application is found on YOUR SERVER, the CUSTOMER never ever ever ever gets to OBTAIN or MODIFY the Application because it is never on THEIR server. You were close, but you keep thinking that the Application somewhat ends up on the Customer's Server and only interfaces with you to obtain Licensing Information. NO, the API would have them use a TINY bit of Code to Interface with the ENTIRE APPLICATION. The License Tracking only offers the Application a secure way of knowing which Company has what License and how many Users are allowed on the Application. In the end I simply suggest changing the Licensing Structure to a 1 Time Fee granting a Perpetual, Non-Revocable, Non-Exclusive License and give the Source Code to the Customer without a User Limitation. Honestly, in my opinion, giving someone the source code and telling them they cannot modify it or use more than an arbitrary number of users is like trying to milk a bull. You may get results, but they won't be the type of results you want. Do you require any more explanation of what I am referring to when I say API? If so, please send me a Private Message and I will try to convey this in a manner that may outline exactly what I am trying to say. Edited Nutshell: The Licensed System is programmed to WORK OFF OF YOUR SERVER. The component to work with the Licensed System ( Your Application ) is handed out to the Customer. The component would be a small feature which has no control over functionality, processing or anything except with predefined methods of what you choose to accept. Your third paragraph is completely wrong as you continue to assume I am suggesting they have the Licensed System ( The Application ) Hosted on Their Server. Kindest Regards, Jumpy09

API is where you own the only copy of the Application / Script and allow Licensees to access it remotely using iFrames, Javascript, cURL, or other methods to obtain information. As I mentioned this would increase your bandwidth consumption and if you ever decided to close down the project, your Licensees may be entitled to obtain a copy of the code since they technically paid for it. That is what I meant by API, not they have the Source Code and then call your server for the permission. They never obtain the script so they never have the chance to alter how the licensing system works. I figure a bit more work would be required to allow this potential to be a realistic implementation, but with PHP Applications you don't really have much of an option.

Depending on the particular application / code, you could set up an API System where they would have to access your single script located on a single server through the API with their API Key to pass various variables through to allow your script to process post / get requests. The system wouldn't really be complicating and you could keep a list of all API Keys in the database to query against to make sure a particular person or company has a License to access that script. A bit more dynamic programming and you can limit how many concurrent users would be allowed to access the script from a particular website / API Account, but it would have to be dynamic as other sites would also be able to utilize this. You would absolutely have to have it set up on SSL and only accept incoming calls from HTTPS:// to prevent any eavesdropping, you may also want to ensure the clients using the API System also have SSL for extra insurance against it. You may also want to find a good way to make sure it is only being called from a Single Server per API Key, so if they wanted to pay for a second server they would need a second API Key to access it. You could Encrypt your code with Source Code Encryption Software, but they have been reversible for quite some time now so people with a higher intellect on technology could get your Source Code from it, so the best option to make sure no one is able to circumvent your licensing system is to set up the API. Of course people would be required to have Internet Access on their servers to utilize it. This would also increase Bandwidth Costs and won't be as clean as if you just gave the Application to the Client, so pricing structure may change a bit to cover the extra costs. The real question you have to ask yourself is: If people were to Circumvent the Licensing System, would you happen to lose more money with the circumvention or would you lose more money with the API System and Bandwidth Consumption. The Encryption Software can be a bit pricey and still doesn't 100% protect your Source Code / Licensing System from circumvention, plus the Client would need to add a Mod onto Apache ( if this is a PHP Application ) to decrypt the encryption if it isn't already included on their Hosting System. Have your Employer run some simulated loss projections from the three methods. Go with a 1%, 5%, 10%, 25% loss projection which states that the percentage of people have circumvented and are using your Application for free. Find out how much output the application would cause in Bandwidth and estimate 10% , 20%, 25% , and 50% of the bandwidth usage would be from First Time ( Full Bandwidth Load) and the rest are concurrent users who have cached some content for use. Also if you go with Encryption, include the cost of the Encryption Software in with the loss projections. If you have a feeling that your system would be very popular, like CometChat, you may also want to flop the loss projections around where the majority are using Free Versions and the minority are using Paid Versions... I do believe, before Adobe changed their system for Licensing for their Creative Suite Products, that more users were using Free Versions of let's say Photoshop than those who had paid for it. Unfortunately with PHP and some other Programming Languages it is a lot harder to protect your Source Code from users who want to use it for free. Even with C++ and other languages which are compiled before use, not during use, there is always the chance for Reverse Engineering, but that is likely to happen and doesn't really cause any losses for your company per say. Hope this is helpful, I figure the best chance of securing your Licensing Arrangement would be the API System but it could potentially prove to be the bigger factor of Losses unless you increase cost per user to cover the additional Bandwidth / Server costs.