mysqli or die, does it have to die?

Question 1

If I use a bit of code like this:

$update_result = mysqli_query( $link , $sql_update_login ) or die ('Unable to execute query. '. mysqli_error($link));

Does it have to die or can you put a different query afterwards? Like a predetermined function that writes a log of the error to another table? Such as:

$update_result = mysqli_query( $link , $sql_update_login ) or function('$query, $error);

What are the other options after 'or'? I haven't found it in the documentation, any clues are appreciated.

Question 2

Does it have to die

Quite contrary, it shouldn't or die() ever.
PHP is a language of bad heredity. Very bad heredity. And or die() with an error message being one of the worst rudiments:

die throws an error message out, revealing some system internals to a potential attacker
it is confusing innocent users with strange messages and leaving them no interface to work with, so they'd likely just drop out.
it kills the script in the middle, so it may cause torn design (or no design at all) shown (i.e. an incomplete render of the page the user requested)
killing the script irrecoverably. While thrown exception can be caught and gracefully handled
die() gives you no hint of the place where the error occurred. And in a relatively big application it will be quite a pain to find.

So, never use die() with MySQL errors, even for the temporary debugging: there are better ways.

Instead of manually checking for the error, just configure mysqli to throw exceptions on error, by adding the following line to your connection code

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

and after that just write every mysqli command as is, without any or die or anything else:

$result = mysqli_query($link, $sql);

This code will throw an exception in case of error and thus you will always be informed of every problem without a single line of extra code.

A more detailed explanation on how to make your error reporting production ready, uniform and overall sensible while making your code much cleaner, you can find in my article on PHP error reporting.

Question 3

<?php
$sql = new mysqli('127.0.0.1','root','Qwert12345','plot_io_db');
//echo $sql->query('Select * From players');
?>

It will work. Just remove port from localhost (127.0.0.1)

Question 4

To mock a type, it must either be an interface (this is also called being pure virtual) or have virtual members (abstract members are also virtual).

By this definition, you can mock everything which is virtual.

Essentially, dynamic mocks don't do anything you couldn't do by hand.

Let's say you are programming against an interface such as this one:

public interface IMyInterface
{
    string Foo(string s);
}

You could manually create a test-specific implementation of IMyInterface that ignores the input parameter and always returns the same output:

public class MyClass : IMyInterface
{
    public string Foo(string s)
    {
        return "Bar";
    }
}

However, that becomes repetitive really fast if you want to test how the consumer responds to different return values, so instead of coding up your Test Doubles by hand, you can have a framework dynamically create them for you.

Imagine that dynamic mocks really write code similar to the MyClass implementation above (they don't actually write the code, they dynamically emit the types, but it's an accurate enough analogy).

Here's how you could define the same behavior as MyClass with Moq:

var mock = new Mock<IMyInterface>();
mock.Setup(x => x.Foo(It.IsAny<string>())).Returns("Bar");

In both cases, the construcor of the created class will be called when the object is created. As an interface has no constructor, this will normally be the default constructor (of MyClass and the dynamically emitted class, respectively).

You can do the same with concrete types such as this one:

public class MyBase
{
    public virtual string Ploeh()
    {
        return "Fnaah";
    }
}

By hand, you would be able to derive from MyBase and override the Ploeh method because it's virtual:

public class TestSpecificChild : MyBase
{
    public override string Ploeh()
    {
        return "Ndøh";
    }
}

A dynamic mock library can do the same, and the same is true for abstract methods.

However, you can't write code that overrides a non-virtual or internal member, and neither can dynamic mocks. They can only do what you can do by hand.

Caveat: The above description is true for most dynamic mocks with the exception of TypeMock, which is different and... scary.

Question 5

mysqli_connect("","username" ,"password","databasename");//Server name cannot be NULL

use loaclhost for server name(In Loacl)

<?php
    $con = mysqli_connect("localhost","username" ,"password","databasename");

    if (mysqli_connect_errno())
    {
        echo "Failed to connect to MySQL: " . mysqli_connect_error();
    }
?>

Or can use MySQLi Procedural

<?php
    $servername = "localhost";
    $username = "username";
    $password = "password";

    // Create connection
    $con = mysqli_connect($servername, $username, $password);

    // Check connection
    if (!$con) {
        die("Connection failed: " . mysqli_connect_error());
    }
    echo "Connected successfully";
?>

EDIT 01

$servername = "localhost";
$username = "root";
$password = "";

Question 6

I've analyzed the code that is precompiled and it would seem that the precompiler automatically resolves the application-rooted paths to relative paths anyway, regardless of what you set the VirtualPath too. I've also tried deploying the same pre-compiled site to different virtual paths on the target server and nothing breaks.

So therefore I'm confident enough to be able to say: no it does not matter what this value is.

No doubt there's bound to be something I've potentially missed - but until I'm proved wrong I'll assume I'm right!

mysqli or die, does it have to die?

Answers

php,mysql,mysqli