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.