ginerjm
-
Posts
6,906 -
Joined
-
Last visited
-
Days Won
99
Posts posted by ginerjm
-
-
If you did all this, WHERE IS THE CODE?
-
So - where is your attempt at getting to your goal? You wrote all the php code (which you really need to post properly next time) but you didn't write the easy part.
-
Without looking at your code, I am curious about your question. Whatever do you mean by asking what the "correct method of sharing a database object/connection"? A script opens a connection, uses it and it goes away when the script terminates. What is the "sharing" you are referring to?
-
Why did you think that using Session vars was the way to go. If you have a 'set' of data, you store it in a table (one data item per field) and use some unique value for that set of data, ie, session, to be the index of the records in the table. Then when you want to get the data for a particular "session" you query for the corresponding key/index.
-
I agree with QOC - why bother with trying to do some hanky-panky with sessions (?) when a db is so simple and direct?
-
Benanamen,
The db parm is there because the same included file is used in all my scripts. Obviously I don't write all my scripts to use the same dbname, so that is why. Make sense now?
-
Then the MySQL functions from my dev.mysql.com are not accurately described for my feeble mind..
-
I put my connection logic into a module by itself as a function. When I'm writing a script that requires db access I make sure to include that file at the top of my script and call the function (in it) when I need to open a connection. I use the dbname as an argument in the call to that function. The function returns the connection handle which I can then use in my script.
My connection code:
// Filename: sql_connection.php function PDOConnect($dbname) { // my connection code follows ... }And when I need it in my script I do this:
<?php .. .. .. require($path_to_php."/sql_connection.php"); $pdo = PDOConnect('my_db_1'); $q = "select......."; $qresults = $pdo->query($q);Of course you only have to make the connect call once in your script, unless you deliberately close it or need another handle to the driver.
-
I did RTFM and am pointing out that it says it creates a datetime field, or a DATE or TIME field and not a string
This is the inverse of the DATE_FORMAT() function. It takes a string str and a format string format. STR_TO_DATE() returns a DATETIME value if the format string contains both date and time parts, or a DATE or TIME value if the string contains only date or time parts.
So his original query was trying to compare the string (type) value that curdate provides against a date(type) value from str_to_date.
Have I read RTFM incorrectly?
-
A good way to solve this problem and many other future ones is to design your script to do ALL of your php work at the top and ALL of your html work at the bottom. That way everything that you want to appear on the page is ready when the html part is sent to the client. It also makes it easier to read and interpret and perform maintenance on at a later date.
In this case - simply set your $pagetitle var once you grab the query result record. PS - why do a loop instead of just a simple fetch since your query appears to only be seeking a single record?
-
I may be confused. You say that you are required to post your source code on your 'partners' server. Is that your client that you are writing this code for? Does it have to be posted as you write it or is that just a requirement of the project's completion? Can you not do your development in a similar environment separate from that server so that you don't show anything until completion and the client is happy and you have been paid?
You can never keep the client from seeing your source code once you have turned it over to him. But at that point, why would you care? OTOH - if your concern is NOT the client, but the users, putting it outside of the web-accessible tree as I mentioned earlier would be the way to go. If your client allows users to have ftp access to those areas, it is out of your control and the client is assuming all of the risks in that situation.
As I said before - your concern is not clear to me. Who and 0what is involved needs clarifying.
-
Did you display the sql error message? It might have pointed you at the problem if you only bothered to do these kinds of things as a beginner.
Always code to check things instead of just assuming that they are going to run for you. Check if a query ran and if not output the message. Check if your db connection succeeded and send an echo if it doesn't. Check if the external file you attempted to open actually was opened. Enable php error checking always when doing development so that you can see and clean up errors as they occur.
Programming is about putting together a fail-safe solution to a problem. Kind of like baby-sitting a two year old - you can't assume anything!
Hint: check for unneeded commas.
-
Barand gave you the syntax for the comparison. I'm trying to tell you that str_to_date will not work Those are the two pieces of your puzzle that you need to work on. Either write a query to convert your table completely or use the correct function in place of str_to_date to get a datetime result for your compare.
Since you apparently don't like to do your own research ( a bad tendency for a future programmer!), here's a link that you should find useful:
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html.
-
Read the function name again. "string to date". It produces a datetime, not a date string like yyyy-mm-dd. Basically it is not a human-readable value.
You say that the input for the completion date field was not in a recognizable format, yet you are trying to use it with a MySQL function. Couldn't you have done that when you imported it and avoided this complexity?
-
Is Completion Date a string or a date field? If it is NOT a string, why are you using str_to_date on it? If it is a string, why isn't it a true datetime field in your database? Would make it much easier to use instead of the format that your format-string implies.
Also - your str_to_date call produces a datetime format value. The curdate function returns a string value. Kinda hard to compare the two.
-
How about SHOWING us the query that is giving you the problem instead of the pre-changed one?
-
1 - you really should use the POST method and not GET.
2 - You retrieve data from a form via the name attribute. As said above, you don't need to name your td elements, only your inputs
3 - Don't understand what you are doing with the first block of code trying to obtain the id values and then the second one trying to get the properly named values. Don't understand at all. Good tip is to practice putting MEANINGFUL text comments in for each step of your thought process to make it easy to follow at a later date.
4 - Turn on php error checking to see if something pops out. Also add some echos to see what progress is actually being made through your script.
5 - Lastly - start to learn and use more modern html. While tables are generally frowned upon nowadays, the used of td to create a label and and a separate input element is also frowned on. Use the label tag and the input tag at the very least.
Lastly again - please use the proper forum tags when posting your code here. Also try to write your code a little neater - use indentation to make it clear what belongs to what. Such as:
if (.....)
{
line
line
line
}
else
{
line
line
}
and so on.
-
And while Godaddy is cheap I've heard that they are not the best people to trust with your server needs. Certainly not in tech support! Find a hoster that offers the products you need (php for one, MySQL for another, emails, backups, ftp access) and offers support (while you will be doing the work, sometimes you need them to step in and make adjustments for you or to clean up email/ip problems when they occur) that is responsive. I've heard that GD doesn't respond very well when asked for this kind of help.
Personal plug here: 123ehost. Disclaimer: I am not an owner or employee, just a happy customer for several years. Cost - anywhere from $3 to $20 a month depending upon your needs and demands.
-
You've been trying to pick up PHP for seven months and apparently haven't read a single thing on logging in and secure methods and good practices? What HAVE you been doing for those seven months?
NEVER carry a password around. You handle a password only for as long as it takes to get it from the user's entry into a login form and create a query to check the db. If the check passes you set a token that tells you who they are (user id?) and that they are logged in (as mentioned - $_SESSION['login'] = 1) or if necessary a token that gives you a value that translates to a security level if your appl requires that to be known. Then you forget the password. You'll not need it again. And god forbid - you will not design your appl to 'help' the user by "remembering" his password. Always make them signin, or at least set a cookie with a reasaonable duration if you must let them remain logged in for a certain window of time.
As for a db login. Store the credentials (user id and password) in a mini php module that is stored outside of your web-accessible tree (I assume you know what that is) and reference that in your standard MySQL connection code (which I also assume that you have) The uid/password is stored in only ONE place this way and not accessible by any of your users - only your php scripts.
After seven months you might want to pick up the learning pace and do some research to educate yourself on these elementary things.
-
You started by saying you needed to let "them" see your code. Did you mean your php code, or the html code that is produced BY that code and that is then sent to the client?
1 - They can't see php code from a browser - it just doesn't work that way.
2 - In order to "see" your PHP code, they would have to download it from the server and use an editor on their client.
3 - If you don't want them to be able to do that you could move the php files to another folder and not allow ftp access to that folder so they can't download them.
You need to clarify what you want to allow and what you don't.
-
Do a dump of your $_POST array to see what is in there right after your script begins.
PS - it would be better if you posted the code, rather than screen prints. Use the proper forum tags to wrap it.
-
This line:
echo '<div class="tboxout" background='$tcgimg'>';
isn't going to do what you think. Your background isn't going to anything. Need double quotes around a string containing a php var, or double quotes around the var itself.
echo "<div class='tboxout' background='$tcgimg'>";
-
You can't recognize the problem? How about you use a $_SESSION var even tho you never started the session?
-
Next time try reversing your use of quotes. Since php recognized any php var that is wrapped in double quotes on the outer side you could have started the query statement with a " and then not have to concatenate all of your vars in the values.
Ex.
$q = "insert into table (field1, field2, field3)
values ('$value1', '$value2', '$value3')";
Much simpler to code and read and works the same as your more complex string.
How to creat a line break in a look
in PHP Coding Help
Posted
When you declare your table, add specific col widths to it so that the format isn't determined by the browser. Look up the <col> tag