PFMaBiSmAd

Probably because the error has nothing to do with phpbb. It's a basic sql question. String data in a query must be enclosed by single quotes. Without the single-quotes, the query is treating the username as a column name. $sql = "UPDATE phpbb_users SET user_gold = 50 WHERE username ='" . $user->data['username'] . "'";

You need to SELECT the values you want. You are only selecting the type and the sum().

Are you developing and debugging your code on a system with error_reporting set to E_ALL and display_errors set to ON (preferably in your master php.ini) so that all the errors php detects will be reported and displayed? You will save a TON of time.

The --without-mssql means that your php was complied without support for mssql and the only things you can do to change that would be to compile php yourself, find a Windows binary that has support for mssql, or use an alternative method - This extension is not available anymore on Windows with PHP 5.3 or later. SQLSRV, an alternative driver for MS SQL is available from Microsoft: » http://msdn.microsoft.com/en-us/sqlserver/ff657782.aspx.

You should only download files from php.net or sites that php.net recommends (such as http://www.apachelounge.com/ ) You need to get the same version of file as your php version and it also needs to be complied with the correct flavor of the c complier. You also need to match the thread-safe or not thread-safe flavor. How did you get and install php? The .msi installer (which requires that you use the Windows control panel add/remove to install php extensions) or the .zip package? For the version of php that you mentioned, it comes with the correct files needed to enable mssql. You can download the official Windows binaries from here - http://windows.php.net/downloads/releases/archives/

The query you tried will match April of 2011, April of 2010, April of 2009,... Matching dates generally requires testing the year as well - SELECT * FROM dos WHERE EXTRACT(YEAR_MONTH FROM your_date_field) = EXTRACT(YEAR_MONTH FROM DATE_SUB(CURDATE(), INTERVAL 1 MONTH))

Yes, it is doing what it is defined to do - http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html See the last rule at that link (in all other cases, the arguments are compared as floating-point (real) numbers.) "2Apples", when parsed as a floating point number results in the value 2 (the first non-numerical character serves as a stop character.)

The code you just posted is executing the query twice. Once by calling the ->query() method and the second time inside the ->fetch_array() method. Why would you want to do that?

The problem is because your ->fetch_array() method is calling your ->query() method. Why are you doing that? You have already executed the query and your fetch_array() method should just fetch the data.

Since php code isn't included when you use a URL, none of the settings that affect if a URL can be used in an include statement are even relevant to the problem, especially since the OP can already use a URL in an include statement. When you use a URL in an include, only the output from the php code gets included, the same as if you browsed to the file. This also takes 50-100 times longer then if you included the file through the file system. Just do what BloodyMind suggested in reply #1 in the thread, include the file using the file system and if needed set up any $_GET variables that the included code needs.

Nested <form></form> tags are invalid (the first opening <form> tag wins.) It sounds like you did not close the first form before you started the next one.

You are trying to retrieve and display information for a specific user. You would keep track of the last message that was processed (displayed) for each user.

So, if you have TableA with a column named ID that you would like to label: 'User id' and TableB with a column named ID that you would like to label: 'Product id', how would this one single list of labels work? You could make all your column names unique, but that is just making unnecessary work for yourself. Whatever you do, you need to keep it general purpose, so that once you test it, you can forget about it, rather than needing to keep track of an ever increasing amount of information as the size of an application grows. Oops, I change an entry in this array to match what I needed this code to do and my code on that page over there now needs to be retested because they were tied together too closely and weren't general purpose enough.

1) Selecting all the columns will use more resources than selecting one column, due to the amount of memory used to hold the data and the processing time needed to transfer that data. (Hopefully, you are not storing images or complete books in your database table as that would cause a huge jump in the resources used if you are selecting the columns with that data in it when you don't need it.) 2) If there is no change in the table data, repeatedly querying with the same query simply returns the result that was previously returned by that query - 3) You can store the 'last message id' somewhere (database, session variable...) so that you will only need to query for rows that have a message id greater than the last one your code processed.

Ummm. The $__TEXT__ array contains information that is specific to one database table. By using the global keyword, you are creating a situation where the function will only operate on that specifically named array of values and you will need to use more code to shuffle around values and you will need to keep track of where you are calling the function from so that you can setup the array correctly before calling the function for different tables (functions are supposed to make coding easier, not more work.) For the same reason that you are passing the $table_name into the function as a parameter (so that you can reuse the code in that function with any table without needing to modify and retest the code in the function each time you use it), you would also pass in the $__TEXT__ array as a parameter along with the $table_name (you could use a single parameter that is an array to hold both pieces of information) or you would write the code in the function so that it would get the correct $__TEXT__ array that matches the table name it was called with.

The problem occurs because the recorded information in the browser's history for the URL is a form submission. When you navigate back to that URL or refresh the page the browser attempts to perform the action it has recored for that URL. There are two things you can do to fix this - 1) After you have successfully processed the form submission, redirect to the same URL. This will cause a GET request for that URL to be recored in the browser's history and it won't resubmit the form data when you navigate back to that URL. 2) Store a value in a session variable that indicates that the form has been processed and skip the form processing code as long as that session variable is set.

$__TEXT__ is the argument that you are supplying to the foreach() loop that is invalid, because $__TEXT__ doesn't exist inside your function. If you are defining/including $__TEXT__ in your main program scope, it doesn't exist inside your function. You need to pass it into the function as a parameter when you call the function (like what you are doing with $table_name.)

It might be doing something, but it is apparently not set as I suggested. You would be getting errors when you reference $__TEXT__[...] as an array or those errors are hidden in the 'view source' of your page because they are being output inside of a html tag. Have you checked the 'view source' of the page in your browser? The only way anyone here can help you with what your code is doing is if you post your code that produces/reproduces the problem. Changing ONE line in your code can prevent it from working. It's new code at that point and if you want help from someone who is not standing right next to you, you need to post it.

What's your current relevant code? Doing an array lookup when you output something is not that hard, provided the starting data exists and has a matching entry in the lookup array. Are you doing this on a system with error_reporting set to E_ALL and display_errors set to ON so that php will help you by reporting and displaying all the errors it detects?

Use htmlentities with the second parameter set to ENT_QUOTES. Or if you want the code color highlighted when you output it - highlight_string

What exactly did you put in the file to change it? Invalid settings or settings with syntax errors, don't take effect. Also, if you used a Windows supplied editor to edit the file, it likely got saved with a hidden .txt extension. Have you turned off the Windows setting that hides extensions for known file types? How did you install php, because some of the all in one packages and the php.net .msi installer package override settings using registry settings and making changes to the php.ini don't do anything.

The phpmyadmin script is failing and outputting nothing. You should have error_reporting set to E_ALL and display_errors set to ON or have log_errors set to ON so that you can get information about any php detected errors. Have you checked the web server error log file -

Are you getting a completely blank page when you tried the suggestions? If so, what does a 'view source' of the page in your browser show?

Have you checked for spelling errors in the function name? Does any of the other code in the web_inventario.php file work?

Your connect_include.php file probably contains some character(s) before the <?php tag or after the ?> tag or the file was saved as a UTF-8 encoded file with the BOM (Byte Order Mark) character. Insure there is nothing before or after the <?php ?> tags and that the file is saved as an ANSI/ASCII file.