Format MySQL Datetime in PHP

If you want to format MySQL's DATETIME type field in PHP, you have several options. So, let's quickly review them.

Option 1. The first option is to use MySQL's built in DATE_FORMAT function. For example, the following SQL command:

SELECT DATE_FORMAT('2009-10-19 22:23:00', '%M %d, %Y');

will return this formatted output: October 19, 2009.

However, just in case you don't want to alter the SQL commands in your scripts, there are a couple of other options as well.

Option 2. This only works in PHP 5 or later.

$myDate = new DateTime($record->date_created);
$myDate = $myDate->format("F j, Y");
echo $myDate;


Give the date_created field contains '2009-10-19 22:23:00', the output will be the same: October 19, 2009.

Option 3. Works with any version of PHP. Here we use PHP's date() function but don't pass the MySQL field directly! Rather, we first convert the value of the date in the field to a timestamp and then use the PHP date() function. Example follows.

$dateTimeStamp = strtotime($record->date_created);
echo date("F j, Y", $dateTimeStamp);


Option 4. This is our last option. The trick is to use MySQL's UNIX_TIMESTAMP function to return a timestamp that we will directly feed into the PHP's date() function. So, this is a sort of combo of Option 1 and Option 3. A quick example is given below.

$recordset = mysql_query("SELECT UNIX_TIMESTAMP('2009-10-19 22:23:00') as date_created");
$record = fetch_as_object($recordset);
echo date("F j, Y", $record->date_created);


Again, you must get October 19, 2009 output.

Finally, here is the URL for MySQL's date and time functions: http://cut.io/wPQ6

Difference Between C# Cast Syntax and the AS Operators

You know what? Sometimes, the most obvious and easy questions are those that are the most frequently asked. One of such questions about C# is the difference between the cast syntax and the as operator. This is sometimes referred to as prefix-casting and as-casting.

Without giving much thought to the difference, you may think that having two constructs for casting is somewhat redundant. However, that's not true. C# is an extremely elegant language and every construct has its place and helps you provide clean code. Moreover, these casts have dedicated operations in the Intermediate Language (i.e. the .NET language).

Let's first list the differences. So, what we have is this.

1. The as operator returns null when casting is impossible (for example, the variable you are trying to convert is not of the requested type). Prefix casting will instead throw an exception.

2. The as operator can be applied only when you want to cast a reference type variable to a reference type. The prefix casting is free of this constraint.

3. The as operator cannot perform user-defined conversions (for example, explicit or implicit conversion operators). A prefix cast can perform these types of conversions.

However, the impact on your code can be more than the above three points describe. First things first. Prefix casting yields to a more reliable code. Why? Because if the cast fails, an exception is thrown right at the moment of casting. With the as operator, no exception is thrown. However, now you have a null reference and once you use the variable, a null reference exception is thrown. Unfortunately, this can be quite far from the place where the cast was performed. Because of this, applications using the as operator can be more difficult to debug.

Some programmers consider the old C style casting ugly. Personally we at P2PSYS Development Studio don't have anything against the prefix casting (probably for our passion towards the C programming language). However, there is one serious benefit in favor of using the as operator. It's way too fast when compared to the prefix casting. We have not done a scientific test but we've heard that the difference is on the factor of five. Imagine now prefix casting used in loops. A real slowdown for your code.

Thus, whenever possible, eliminate the casting at all, especially in long loops. If, however, casting is impossible to avoid, then use the as operator. But try to do a check right after casting. This will give you a fast and a clean code and a code that is elegant to read and easy to debug.

String Concatenation in MySQL

String concatenation is a frequently used operation in programming languages and in SQL as well. In many programming languages + operator is used for string concatenation. There are exceptions of course. Take PHP, where dot (.) is used for string concatenation. The same is true for SQL. For example, in Oracle you can use a double pipe () or a special operator CONCAT. Microsoft implementations (SQL Server, Access) do not have a CONCAT operator. Rather, + operator is used for string concatenation.

When it comes to MySQL, here you can use the CONCAT operator or above mentioned double pipe . However, there is one caveat. In order two use the double pipe, this must be enabled in sql_mode variable. Unless you've added PIPES_AS_CONCAT mode to your sql_mode variable, double pipe will return zero.

Let's bring quick examples.

SELECT CONCAT(columnA, columnB, 'literal A', 'literalB');

or

SELECT columnA columnB 'literal A' 'literal B';

Again, for the second example to work, you must set the sql_mode either from a command line like this:

SET sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,
NO_ENGINE_SUBSTITUTION,PIPES_AS_CONCAT';


or via the settings file like this:

sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,
NO_ENGINE_SUBSTITUTION,PIPES_AS_CONCAT"


in my.ini or my.conf for Windows and Unix/Linux respectively.

FormView.ChangeMode Problems

ASP.NET's FormView web control has a ChangeMode method to programmatically switch the FormView control between Edit, Insert, and Read-only modes. However, this method can be a source of many headaches. If you are calling the ChangeMode method but the FormView does not actually change the mode (e.g. to Edit mode from Insert mode) then keep on reading.

You will certainly run into the above mentioned situation if you call the ChangeMode method before the FormView is bound to the data. Suppose you have a FormView named myFormView and bind it to data coming from a custom business object. Suppose also that initially the FormView was in the Insert mode. The fragment of the code is given below.

myFormView's mode is Insert.

.... // SOME CODE

myFormView.DataSource = myBizObject.GetBizObjects();
myFormView.DataBind();
myFormView.ChangeMode(FormViewMode.Edit);

... // SOME CODE


Now you expect the myFormView to actually change the view from Insert to Edit. It simply wont. You may spend a good hour debugging your code and scratching your head to figure out what's wrong. This is what is wrong. To change to Edit mode, the FormView absolutely needs a current record. In other words, you must change the mode once the FormView is already data bound.

So, to fix the problem, you must handle the OnDataBound event and change the FormView's mode there. Thus, we add the following event handler:


protected void myFormView_DataBound(object sender, EventArgs e)
{
myFormView.ChangeMode(FormViewMode.Edit);
}


It was easy, wasn't it?

Best IDE for Android Development

Google Android is an amazing mobile operating system. At the same time, Android is the youngest mobile system and as such in our opinion has the most potential for new developers. If you have ever programmed for Symbian operating system, you know what complicated it is. Android, on the opposite is an elegant system and the development is done in Java (though native code is possible but is usually used for performance critical parts). The Android SDK is very nice as well.

If you have programmed in Java, then you can do Android coding in an IDE of your choice. If you use NetBeans, you can keep it for Android.

However, Eclipse is most tightly integrated with Android. Therefore, if you are just starting programming in Android, we recommend that you use Eclipse. If you are a long time NetBeans or other IDE user, you can use it with Android but give Eclipse a try.

You can make a simple experiment. Try to create a Hello World application in Eclipse and in any other IDE and see which path will take you the least time.

How to Get Rid of PHPSESSID

Removing PHPSESSID from URLs is quite easy. However, beginner PHP developers usually struggle with this problem. If you don't think that having the PHPSESSID in your URL is not a problem, then think twice. First, this problem makes your website less search engine friendly. Secondly, having PHPSESSID in a URL increases security risks. Finally, it just ruins the aesthetics of your URLs. So, let's get rid of it.

Depending on your environment, you may need to use one of the alternative solutions given below.

Method 1. If you have access to the php.ini file, then the easiest way is to modify it. You need to make the following adjustments:


session.use_only_cookies=1
session.use_trans_sid=0


Method 2. Your hosting refuses to change the settings? No problem. Make sure to add the following snippet to a PHP file that will be included in all your files.


<?php
ini_set('session.use_trans_sid', 0);
ini_set('session.use_only_cookies', 1);
?>


Make sure to include both lines. Some resources mention to add the first line only. Unfortunately, that does not solve the problem unless you add both commands.

If you are on a shared server and this function is disabled then you have to resort to method 3 given below.

Method 3. In your .htaccess file, use the code below:


php_value session.use_only_cookies 1
php_value session.use_trans_sid 0


Place this file in the webroot of your website.

It was really easy, wasn't it?

Welcome to Fresh Tips for Developers

Welcome to a new blog created by P2PSYS Development Studio developers for fellow developers out there. The main purpose of this blog to share our experience and knowledge with the development community.

Knowledge is power and sharing knowledge is vitally important for making development community more effective and efficient.

Our plan is to post short but concise posts about different aspects of development. The posts will have tip-like orientation. In other words, every post will be brief and focused on solving certain, "local" problems that real-world developers face daily.

We hope this blog will become a favorite place for beginner developers and seasoned developers alike.