SELECT LEFT(‘string’, number_of_characters)

To get the 7 left-most characters from a specific column in every row of a table the following would work:

SELECT LEFT(name, 7) FROM fict_chars

It should be noted for this and for other functions that if the string is in single quotes that SQL will see it as a literal string. If it is not, SQL will see it as a column. Thus, had we used ‘name’, the result would have been “name” for each row, and not the actual name drawn from the specified column.

Just because they look alike...

Generally I am a fan of SQL and how it works, but there is a function that I find irritating. Not because of what it does, but because of its name, “INSERT()”. Why, oh why would you give a function the same name as a statement that already exists? I am sure there is a story behind this and it probably goes back to family squabbles occuring in the 10th century AD, or at least to the 1970s when Chamberlin and Boyce first conceived RDBMS. Suffice it to say that it could cause confusion when quickly glancing over code or when newcomers are learning the language.

Just know that the two are different. The statement is the familiar, much used instruction to the database to add a row to a table.

INSERT INTO table (column1, column2, etc.)
VALUES(‘value1′, ‘value2′, ‘etc.’)

Meanwhile, the INSERT() function is designed to replace text within a string. It does this using the following syntax:

INSERT(‘string’, position, length, ‘inserted_string’)

The first parameter is the string to be operated upon. The position is where the insertion should begin. Length defines how many characters should be replaced. The fourth parameter is the string to be injected.

A simple example:

SELECT INSERT(‘Jane Porter was the heroine in Harry Potter.’, 32, 12, ‘Tarzan’)

Our result, “Jane Porter was the heroine in Tarzan.” Note that the character specified in the second parameter is over-written as are the subsequent 11 characters, 12 characters in all.

SELECT FIELD(‘string_to_match’, ‘string1′, ‘string2′, ‘etc.’)

Here is the field function in action:

SELECT FIELD(‘Scarlet’, ‘Melanie’, ‘Rhett’, ‘Scarlet’, ‘Ashley’, ‘Scarletta’)

This will return “3″. Though 5 contains “Scarlet”, it is not equivalent to “Scarlet”. Had position 5 also been equivalent to “Scarlet” the result would still have been only “3″. Later matches are ignored.

Both FIELD() and ELT() are a kind of test. They can be used when you are looking for one item out of a group of alternatives. The result can be cranked through a series of if/then statements or switch/case to determine a course of action. This is another place where some of the work done by the server can be taken on by the database.

Read more about SQL Functions.

My problem with the EXPORT_SET() function is that I was having trouble figuring out what I could do with it. So I investigated this aspect for an hour or two, surfing here and there I found nothing that would explain why you would ever want to use a function that basically returns an array of bits that comprise a number and lists them in reverse order. Obviously someone wrote this function for a vital purpose. I thought the purpose mignt be found in the name. EXPORT is a clue. After thorough investigation I see it has been used to port data between applications. A few thought experiments made me realize it could also be used in security as a means of encrypting data. I am sure there is more to it.

Be Secure...LOG OUT!

You know why it is important to log into your account on your various secure destinations.  First, you can’t access your info unless you do! But more importantly no one else can access the info unless he or she can get your user name and password.  So your account is safe right?

Wrong, there are devious ways of getting your user name and password. One easy way is through packet sniffing. I am convinced that packet sniffing is a routine operation around hotels, restaurants, etc. I have had my servers broken into TWICE while I was on vacation. Both times it was after I logged into an FTP account. Malware was installed both times and it was alot of work to get things straightened out, not to mention the fact that all that time spent trying to fix the problem put a damper on my vacations.

Well, there is no better learned lessons than those acquired in the school of hard knocks. I put my servers on SSH. That was just the start. I reviewed all php code and forms on the site. I created software to monitor changes to vulnerable pages and severely limited access to website code. Any suspicious onsite changes are logged and I am notified by email. That was two or three years ago, and I have been unassaulted since. However, without taking further precautions, I could still have been vulnerable to attack. In fact we are always vulnerable to attack, even with seemingly secure accounts especially if we go about getting into accounts while using publicly provided internet. Because through packet sniffing (someone watching the flow of traffic on a particular hub) doesn’t always need a password and a user name. They can simply piggy-back their way into your account by mimmicking your authentication process and headers. As long as your account is open a hacker could theoretically operate inside your account. The way to preclude or at least foreshorten this possibility is to LOG OUT!

I presume you are already savy enough to know that you must log out of accounts and close the browser on public computers so the next user can’t access your account.

For the user taking advantage of a “hotspot”, the best policy, especially in a public place is to make sure to have a secure connection (look for the green bar on the Url at the top of the page), know what you want to do when you log into your account, get your business done, and don’t forget to log out.

What to do? What to do? I could write an application that would change it to a different ad, maybe Chitika, when a Kindle browser shows up. In fact, I probably will do that for one or two of my sites, but so far Kindle web traffic is not high enough to worry about it too much. I have not seen too much traffic thus far from the fire, but it is sure to grow the way the item has been selling. On the other hand it seems to be a device more in tune with selling books, mags, music, and movies. The internet side will probably grow slowly. No doubt the situation can change as well.

In any case, I find Amazon’s approach interesting and also disturbing. Blocking ads on my websites is like stealing content from me. It is amazing how the big boys never play by the rules. The only way I can continue to create content is to get paid for doing so. Meanwhile I am sure the boys at Amazon think they are only tweaking Google.

It’s just one more development to react to.

In any case, I decided to do a redesign of Learn Chess Rules. I decided to employ this design concept in the simplest manner possible, using something close to primary colors. I wanted to see the format in its essense. I also employed a fixed div at the bottom of the page. I like the effect, but the wife liked the ambiance of the site before I changed it. At this time many of the support pages are still in the old format, the FAQs for example, so you can see the difference.

I originally wrote the Chess Rules site in 1998. My memory has me starting at ten in the evening and working to four in the AM. If so, I was working fast. The redesign and rewrite took me two days.

The internet moves faster than a speeding bullet, and even faster than Superman. When I wrote the site it was all tables. Even though in the rewrite I employed a table here and there, where appropriate, the entire structure hangs on the <div> tag and the CSS behind it.

X and Y Axis at Learn Chess Rules

Thus, SQL gives us the ability to GRANT and REVOKE. Actually, on php myadmin in cpannel, you cannot do this with an SQL command, it is done through a UI when the user is created. Basically GRANT gives permission to do various things, and REVOKE takes those permissions away.

The system works logically in that a user has no permissions unless first granted them. Thus we have no REVOKEs without first, somewhere along the line, having a GRANT. The key to GRANTs is to keep them to a minimum. The less access users have to a database the less likely they are to screw things up. Of course, this must be balanced with the needs of the many, which Spock will tell you, out-weighs the needs of the few, we happy few, we band of brothers. Never thought you would see Spock and Henry V quoted in the same sentence did you? Suffice it to say there is a balance.

For most purposes, REVOKEs are used when an empolyee leaves a company or a user loses status (say a subscription lapses).  The syntax for REVOKE follows:

REVOKE privilege
ON object
FROM user or PUBLIC or role

For a GRANT, just replace “REVOKE”.

SELECT IFNULL(column1, “alternative”) FROM table

So if the expression in column1 turns out to be NULL you can make it something else.

Where it gets a bit confusing is that some applications use ISNULL() the way mySQL uses IFNULL(). And some use a completely different syntax. NVL() is how it looks in Oracle.

But there is another way of doing this available in most applications. It is called COALESCE(). This looks alot like IFNULL (mySQL) but has the added feature that it can take multiple parameters and will in the end return the first one that it finds that is NOT NULL. So you can do something like this:

SELECT COALESCE(column1, column2, etc., “alternative”) FROM table

This will return the first not null param that it runs across. Leave the failsafe for the end.

For example, we have a list of customers and a list of transactions. We have a customer number for each customer and that customer number is listed in the transaction log. Since we already have all the info we need about our customers in the customer table, we do not need to also store it in the transaction log. All we need do is list the customer number. So when we need to send an invoice to a customer, we can perform a JOIN on the two tables. This will recall the transaction and with the reference to the customer table get the name, address, etc. Alternatively we could also use a JOIN to find all of the transactions by any specific customer.

For the NEWBIE there is a bewildering list of SQL JOINs. Yet they all have a purpose:

First there is the INNER JOIN. This combines the information from two tables based on a comparison of two columns. It outputs only rows that are found in both tables.

A LEFT JOIN will output all the rows in the left table (or first) table and any associated info from the right table. If there is no info from the right, it will leave those cells blank.

The RIGHT JOIN is similar to the left, only in this case, it is all the rows on the RIGHT that will be listed with unfilled cells left blank.

A FULL JOIN is like a RIGHT and LEFT JOIN together. All rows are listed with the appropriate rows meshed. Blanks will be left in rows with unmeshed fields.

To confuse matters perhaps slightly, there is also the UNION. This works alot like a JOIN only it combines two SELECT statements rather than tables. The result is a list of all the unique info from two selections from like table columns.

Hope that clears things up.