PFMaBiSmAd

Your code has no error checking/error reporting logic in it to get it to tell you if the upload worked or failed or why it is failing. You must test if $_FILES array contains anything and then you must test the $_FILES["file"]["error"] element before you attempt to access any of the uploaded file information. You are probably exceeding one of the size limits. Ref: http://in2.php.net/manual/en/ini.core.php#ini.post-max-size http://in2.php.net/manual/en/features.file-upload.errors.php Also, you cannot set file_uploads or upload_max_filesize in your script. They must be set before your script executes.

You are resetting the counter inside of your loop, so of course all the colors will be the same. systemick told you to reset the counter before you output the html for the table.

Most BOT scripts set 'HTTP_REFERER' to match the site they are 'visiting' because they want you to think they are a 'real' browser that just fetched your form from your site.

That one -> "throw an error"

You are not providing any information in your post that would pin down what is needed. Where these files are located (are they all in one folder or spread out over 1000's of folders that are inside of a common folder) and what are their names (do they have a common naming format, do they have a common extension?)

Are you doing this on a system with error_reporting set to E_ALL and display_errors set to ON so that all the php errors would be reported and displayed, such as header errors that would prevent session variables from working?

Using available information, the following will convert your values into a DATETIME value - SELECT CONVERT(CONCAT('20',SUBSTR('1100803040000000',2,12)),DATETIME); Just the DATE part would be - SELECT CONVERT(CONCAT('20',SUBSTR('1100803040000000',2,6)),DATE); You can than use the resulting DATE or DATETIME values in the rest of the query. You should actually perform the conversion when the values are inserted so that you can operate on native DATE or DATETIME values. The queries will execute much faster.

Ummm. Posting the conversion algorithm or a link to the definition would certainly help someone help you.

You already have a thread for this problem. Don't start another one. I would probably help if you actually provided an actual example showing what you are talking about (in your original thread.)

You can do that in the query as well...............

If you install the aspell executable on your computer, a programming editor like Notepad++ will spell check your file.

SELECT SUM(tx_count) as total FROM your_table WHERE your_where_condition_here GROUP BY service,date

Justin L H, no one here is standing right beside you. When you don't post what you see (including showing any debugging output, such as echoing the values on both sides of a comparison that does not seem to be working) when you execute your code on your server, no one can help you.

There's also about 5-6 errors in the INSERT query that using mysql_error() in some error checking and error reporting code will help you find.

Also, your CREATE TABLE query contains the following errors (you must use error checking and error reporting logic in your code at all times) - 1) There is an extra comma near the end, right before the final ) 2) The ConsultantZip column is duplicated 3) You haven't defined the AUTO_INCREMENT column as a primary key

You should be developing and debugging this on a local development system and only put it onto a live server once it is complete and tested. It should also take at most a few seconds for your entire script to run, assuming that your connection to the database server is occurring without error. Also, when you are learning or developing a new application, you do it in steps. You make your form and check that the form data was received correctly. Then you do any setup code necessary for the database. Then you finally process the data and form the query. Lastly, you put in the code to execute the query.

To make the content of form fields persist between page requests, you must write the value you receive from a form submission into the value="..." attribute of the form field. If you are referring to a type="file" input field, that field can only be set by the browser's file dialog box and cannot be made to persist between page requests.

If your code that inserts 40,000 rows is taking more than a few seconds, there is probably something wrong with your code and you would need to post it in order to get help with it. I'm going to guess you are putting a query inside of a loop. You should either be using a multi-row INSERT or a INSERT ... SELECT statement.

You would better off using a correct DATE or DATETIME data type to store your information in the table (that's what the DATE or DATETIME data types are for.) The second query that Vikas Jayna posted does get the three pieces of information you asked about, using the mysql MONTH(), DAY(), and YEAR() functions in the query. I would use alias names for each part so that it is simpler to reference them when you retrieve the data in your php code.

The most important piece of information would be your form that contains the html for the checkbox fields? They are likely not getting set because of an error in the form.

The form tag needs an enctype attribute. Perhaps if you read the upload handling section in the php documentation first - http://www.php.net/manual/en/features.file-upload.php

It's not actually the web server that makes the connection. It is the other way around, the client connects to the server. The server just uses the existing connection that was made by the client. The connection is kept alive for an amount of inactivity time that is specified either in the Windows registry (IE) or in the browser settings. If the client does drop the connection, there's nothing the server can do about it. Since the web server doesn't have the ability to set the keep alive/inactivity time out, you should not plan on trying to make a connection work this way.

If you are only storing/retrieving them as is and you are not planning on searching for any of the values (i.e. you don't need to find the 44 in your example list), then storing them as a comma separated list is ok. Searching for the values is a different matter and if you plan on needing to search, you should store the individual values as one per row in a different table that is tied to your main table using a key/id value. And what threw me off about if this was adding a decimal (.20) to the value was your use of the + in the first query posted.

Assuming you are doing this to represent adding a fractional number, using the comma , as a decimal point separator character is a human convention that is only used in specific geographic locations. Computer programs uses a decimal point . as the decimal separator character. If you want to use the comma , as a decimal point separator, you will need to convert the number into your local representation when you display it. It is not stored that way and you don't perform computer operations on it that way. If you are doing this to store a list of comma separated values in one field, it is a bad idea.

Literal date values must be enclosed in single-quotes inside the query, otherwise they look like a mathematical expression (2010 - 08 - 02 equals 2000).