Leon's PHP/MySQL project Q/A thread

[LeonLatex]

After destroying a lot of the script that Barand set up for me, I have concluded that developing a lot of what cannot be fixed is the simplest thing than patching together what he developed for me. I should be able to save the rest. Ie. database, calculations, etc. It is the creation/acquisition of variables, connections, sessions, classes, etc. which needs to be set up again. It will be a bit of work, but I think I fix most things on my own now. I will certainly come back to you for tips and advice. I need at least parts of it to put together a music collection management. At least I feel that I have come so far, and then so far that I manage more or more alone and without help from the books, but their professional assessments and tips will always come in handy.

That is why I create this thread get to have a fixed thread and relate to it when it comes to this project I am now starting on.

I have created a DB connections script. Can I get an assessment of this? I try to run it as a stand-alone script gets to test it and get only 500 errors. What is the reason for that?

<?php
{
$pdo = new PDO('mysql:host=sql31.mcb.webhuset.no; dbname=*****;
charset=utf8' , '**********' , '**********');
$PDO->setAttribute(PDO::ATTR_ERRMODE,
PDO::ERRMODE_EXCEPTION);
//Gjør noe nyttig
//Setter variablene $title and $output
}
CATCH (PDOException $e) 
{
$output = 'Unable to connect to the database server: '
. $e->getMessage() . ' in '
. $e->getFile() . ':' . $e->getLine();
}
include_DIR_ . '';
?>

 

[benanamen]

You are missing the TRY for your CATCH

[LeonLatex]

10 minutes ago, benanamen said:

You are missing the TRY for your CATCH

OMG, What a h... Now i feel really embarrassed. I removed it and forget to put it back after check whats happening without it.🤪

[mac_gyver]

there's no good reason to have a try/catch block for the connection code. this is just typing for nothing. a connection error is a fatal problem for a database dependent web page. just let php catch any connection exception, where php will 'automatically' display/log the connection error for you. Keep It Simple (KISS.)

[LeonLatex]

14 hours ago, mac_gyver said:

there's no good reason to have a try/catch block for the connection code. this is just typing for nothing. a connection error is a fatal problem for a database dependent web page. just let php catch any connection exception, where php will 'automatically' display/log the connection error for you. Keep It Simple (KISS.)

I guess you mean this because of security reasons among others...?

[LeonLatex]

I still try to make this work. I have the TRY included now, and out of what I can see and my knowledge and understanding I have to throw it in and ask:

What have i done wrong here?

<?php
try {
    $pdo = new PDO('mysql:host=sql31.mcb.webhuset.no; dbname=**********;
    charset=utf8' , '**********' , '**********');
    $PDO->setAttribute(PDO::ATTR_ERRMODE,
    PDO::ERRMODE_EXCEPTION);
    $output = 'Database Connection Etablished.';
} 
catch (PDOException $e) {
    $output = 'Unable to connect to the databese server: ' . $e;
}
include __DIR__ . '/../templates/output.php';
?>

When I open this stand alone without ERROR report i get a 500 error.
With the ERROR report I get this:
 

Edited July 4, 2022 by LeonLatex

[ginerjm]

You have $pdo and $PDO.   What do you think?

[mac_gyver]

it means only write code that contributes something useful to what your application is trying to accomplish.

for connection errors and errors from query(), prepare(), and most execute() calls (except for duplicate or out of range errors when inserting/updating user submitted data), there's nothing the visitor to your site can do to recover from the error, they are due to programming mistakes or a database server that's not running, ... therefore, there's no point in writing any code for these cases. just let php catch the exceptions in these cases and display (when developing code/query(ies)) or log (when on a live/public server) the actual error information, so that you, the programmer/developer, will know when these type of errors are occurring, so that you can find and fix what's causing them.

the only types of database errors that the visitor to a site can do anything about are when inserting/updating duplicate or out of range visitor submitted data. this is the only case where having database error handling code in your application will do anything useful. you would catch the database exception, test the error number, setup a message telling the visitor exactly what was wrong with the data that they submitted, so that they can potentially submit a different value that will succeed.

[LeonLatex]

10 minutes ago, ginerjm said:

You have $pdo and $PDO.   What do you think?

I just got to laugh  🤪🤓😂👍

I change to PDO 

I should have seen it that myself🤬 I think I need to check my glasses🙄

Thanks ginerjm, it's working now 👍😊

[ginerjm]

Personally I always use lowercase for var names.  Never have any confusion that way.

[LeonLatex]

27 minutes ago, mac_gyver said:

it means only write code that contributes something useful to what your application is trying to accomplish.

for connection errors and errors from query(), prepare(), and most execute() calls (except for duplicate or out of range errors when inserting/updating user submitted data), there's nothing the visitor to your site can do to recover from the error, they are due to programming mistakes or a database server that's not running, ... therefore, there's no point in writing any code for these cases. just let php catch the exceptions in these cases and display (when developing code/query(ies)) or log (when on a live/public server) the actual error information, so that you, the programmer/developer, will know when these type of errors are occurring, so that you can find and fix what's causing them.

the only types of database errors that the visitor to a site can do anything about are when inserting/updating duplicate or out of range visitor submitted data. this is the only case where having database error handling code in your application will do anything useful. you would catch the database exception, test the error number, setup a message telling the visitor exactly what was wrong with the data that they submitted, so that they can potentially submit a different value that will succeed.

 

Yes, because that's what's important. That I get the information is what is important, and where in the script it arises. A visitor to a website will never have any honest intentions or benefit from getting the info that comes up.

Edited July 4, 2022 by LeonLatex

[LeonLatex]

6 minutes ago, ginerjm said:

Personally I always use lowercase for var names.  Never have any confusion that way.

I am the opposite. This is something hanging with me from the old days. I can't explain it, but I have many times tried to change it. But I am always going back to the old.

When i write CSS or HTML I am using lower case. No problem, but when i am in programing mode, NO WAY! No one can explain it.

[ginerjm]

Hmmm...  So if you can't change from using uppercase, how the heck did you get a variable named $pdo?

[LeonLatex]

3 hours ago, ginerjm said:

Hmmm...  So if you can't change from using uppercase, how the heck did you get a variable named $pdo?

I didn't say I can't. I said When i try to change back....
I think this is something that is left behind by my lecturer when I studied. He always used capital letters. It is many years ago, but I think it remains in the basics from that time. As I said, I have tried many times to change to lowercase letters, but for one reason or another I end up back. Now I have re-written all I have done and written in uppercase, so we'll see how long it takes before I end up back on the old track.

Is it only me or am I struggling with my English?😂

[Barand]

In the early days of computing the interface with the computer was through punched cards and paper tape. Output was via line printers and teletype machines. All these devices had a character set limited to a few punctuation symbols, numbers and uppercase letters. Hence in the older programming languages, such as as COBOL, FORTRAN, BCPL, the convention was to use upper case (as these had to be input via devices only only having upper case charsets). They didn't use lowercase because they couldn't - we can.

Since the late seventies/eighties languages like C, C++, Pascal, Java came to the fore, and with terminal input and improved print output, lowercase became the convention. Lowercase gives improved readability as the letter forms are more distinguishable than upper case.

If you have a penchant for upper case, treat yourself to a Cobol compiler and go fully retro.

[ginerjm]

When I suggest going all lowercase it is simply because PHP is a case-sensitive language.  To avoid having to 'remember' how to spell certain var names because one has chosen to type it differently is a clumsy situation to be in, as you proved to begin this topic.  Do what you will but when you continue to have this issue crop up perhaps your mind will change.  Certainly, IMHO lowercase is much easier to read than all caps is.

(Please don't quote me back my own post.  Kind of annoying.)

[Barand]

Thsi topic has a solution so it's time to close it before it drags on aimlessly like your previous one.

If you think we will let you open a topic that will continue in perpetuity while you learn PHP and associated software, think again.