Hello,
I am creating my first database in MySQL. It will contain a
table 'customers':

CREATE TABLE `rozgloszenia`.`customers` (
`customer_id` INT UNSIGNED CHARACTER SET utf8 COLLATE utf8_general_ci NOT
NULL AUTO_INCREMENT,
`town` varchar(40) CHARACTER SET utf8 COLLATE utf8_general_ci,
`email` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci,
`phone` DECIMAL(9,0) UNSIGNED CHARACTER SET utf8 COLLATE utf8_general_ci,
`first_name` VARCHAR(25) CHARACTER SET utf8 COLLATE utf8_general_ci,
`surname` VARCHAR(40) CHARACTER SET utf8 COLLATE utf8_general_ci,
PRIMARY KEY (`customer_id`),
INDEX `customer`(`town`, `email`, `phone`),
INDEX `name`(`surname`, `first_name`)
)
ENGINE = MyISAM
CHARACTER SET utf8 COLLATE utf8_general_ci;

Here is the problem:

Error executing SQL commands to create table.
MySQL Error Nr. 1064
You have an error in your SQL syntax; check the manual that corresponds to
your MySQL server version for the right syntax to use near 'CHARACTER SET
utf8 COLLATE utf8_general_ci NOT NULL AUTO_INCREMENT,
`town` var' at line 2

Could you me plase?
/RAM/

R.A.M. wrote:
> Hello,
> I am creating my first database in MySQL. It will contain a
> table 'customers':
>
> CREATE TABLE `rozgloszenia`.`customers` (
> `customer_id` INT UNSIGNED CHARACTER SET utf8 COLLATE utf8_general_ci NOT
> NULL AUTO_INCREMENT,
> `town` varchar(40) CHARACTER SET utf8 COLLATE utf8_general_ci,
> `email` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci,
> `phone` DECIMAL(9,0) UNSIGNED CHARACTER SET utf8 COLLATE utf8_general_ci,
> `first_name` VARCHAR(25) CHARACTER SET utf8 COLLATE utf8_general_ci,
> `surname` VARCHAR(40) CHARACTER SET utf8 COLLATE utf8_general_ci,
> PRIMARY KEY (`customer_id`),
> INDEX `customer`(`town`, `email`, `phone`),
> INDEX `name`(`surname`, `first_name`)
> )
> ENGINE = MyISAM
> CHARACTER SET utf8 COLLATE utf8_general_ci;
>
> Here is the problem:
>
> Error executing SQL commands to create table.
> MySQL Error Nr. 1064
> You have an error in your SQL syntax; check the manual that corresponds to
> your MySQL server version for the right syntax to use near 'CHARACTER SET
> utf8 COLLATE utf8_general_ci NOT NULL AUTO_INCREMENT,
> `town` var' at line 2

Try with:

CREATE TABLE `rozgloszenia`.`customers` (
`customer_id` UNSIGNED INT NOT NULL AUTO_INCREMENT,
`town` varchar(40),
`email` varchar(50),
`phone` UNSIGNED DECIMAL(9,0),
`first_name` VARCHAR(25),
`surname` VARCHAR(40),
PRIMARY KEY (`customer_id`),
INDEX `customer`(`town`, `email`, `phone`),
INDEX `name`(`surname`, `first_name`)
) CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = MyISAM;

If you have phone numbers starting with a zero, then they will be stored
without the leading zero's, so a varchar may be a better option.

--

//Aho

On Apr 5, 5:05 pm, "J.O. Aho" <u...@example.net> wrote:
> R.A.M. wrote:

> If you have phone numbers starting with a zero, then they will be stored
> without the leading zero's, so a varchar may be a better option.
>

IMHO, varchar is *always* a better option for any data that you can't
do arithmetic on.

Social security numbers, zip and postal codes, phone numbers, etc.

Since "Square Root of Phone Number Plus 5" doesn't make any sense, use
varchar.

On Apr 5, 9:18 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> ThanksButNo wrote:
> > On Apr 5, 5:05 pm, "J.O. Aho" <u...@example.net> wrote:
> >> R.A.M. wrote:
>
> >> If you have phone numbers starting with a zero, then they will be stored
> >> without the leading zero's, so a varchar may be a better option.
>
> > IMHO, varchar is *always* a better option for any data that you can't
> > do arithmetic on.
>
> > Social security numbers, zip and postal codes, phone numbers, etc.
>
> > Since "Square Root of Phone Number Plus 5" doesn't make any sense, use
> > varchar.
>
> Oh, no. Now you've figured out my secret speed dial codes. I'm going
> to have to change my algorithm...
>

LOL!!

ThanksButNo wrote:
> On Apr 5, 5:05 pm, "J.O. Aho" <u...@example.net> wrote:
>> R.A.M. wrote:
>
>> If you have phone numbers starting with a zero, then they will be stored
>> without the leading zero's, so a varchar may be a better option.
>>
>
> IMHO, varchar is *always* a better option for any data that you can't
> do arithmetic on.
>
> Social security numbers, zip and postal codes, phone numbers, etc.
>
> Since "Square Root of Phone Number Plus 5" doesn't make any sense, use
> varchar.
>
>

Oh, no. Now you've figured out my secret speed dial codes. I'm going
to have to change my algorithm...

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================