Hi,
Try this:
To modify an existing field:
ALTER TABLE doc MODIFY docts timestamp DEFAULT CURRENT_TIMESTAMP;
or
To add new field
ALTER TABLE doc ADD docts timestamp DEFAULT CURRENT_TIMESTAMP;
Thanks,
ViSolve DB Team.
- Original Message -
From: "Peter Lauri" <[EMAIL PROTECTED]>
To:
The original message was received at Mon, 28 Aug 2006 09:00:17 +0200
from mysql.com [196.94.146.79]
- The following addresses had permanent fatal errors -
- Transcript of session follows -
while talking to lists.mysql.com.:
>>> MAIL From:[EMAIL PROTECTED]
<<< 501 [EMAIL PROTECT
Hi all!
I got it to work! :-)
And all I did was replacing "IS NULL" with "= '-00-00 00:00:00'" in
the DELETE-statement...
Does anyone have an explanation for this...?
Regards,
Evert
Michael Stassen wrote:
> Evert wrote:
>> Hi all!
>>
>> Who can tell me why the following does not work.
Ratheesh K J wrote:
> Hello all,
>
> Currently our application and MySQL server are on the same machine.
>
> When should these be seperated?
>
When:
- your performance is dropping, and
- you have identified that your bottleneck is CPU usage, and
- both your MySQL server and your applicati
Ratheesh K J wrote:
Hello all,
Currently our application and MySQL server are on the same machine.
When should these be seperated?
What are the main reasons that we should be having a seperate DB server?
There are at least three possible reasons. First, if your applications
are using lot
Hello all,
Currently our application and MySQL server are on the same machine.
When should these be seperated?
What are the main reasons that we should be having a seperate DB server?
Ratheesh Bhat K J
On filesystem level I made all rescue trials. My problem is, that only the
MYD
file is still available. I tried reconstructing it with "myisamchk -r -o
table_name.MYD", but as I said without the wanted result.
MYD is your data, MYI is your indexes (Indexes are easy to rebuild, you
should not w
> At first - do not write anything on the corrupted disk until You have
> finished rescuing data. As I understad the crash is connected to HW or
> filesystem (FS) failure (HDD).
Ok, I will do it more clearly. The server has two harddisks, one for the
system, one for the data. The system harddisk
Question, I specify with openssl is with --wth-openssl=/usr/contrib
and the config script chokes. What is this happening?
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
MySQL General Mailing List
For list archives: http://li
Evert wrote:
> Hi all!
>
> Who can tell me why the following does not work...?
>
> When I do:
> SELECT COUNT(*) AS counter FROM table1 WHERE condition1 = 'A' AND
> condition2 IS NULL;
>
> it returns:
> +-+
> | counter |
> +-+
> | 2 |
> +-+
>
> Then I do:
> DELETE FROM
PS: I already tried with "myisamchk -r -o *.MY*", but then all datasets
are gone and the table is empty. :-(
man myisamchk
I tried myisamchk already. But after running the above rescue attempt, the
tables are empty.
Then I hope you made backups You, do keep backups right?
--
Chris
-
At first - do not write anything on the corrupted disk until You have
finished rescuing data. As I understad the crash is connected to HW or
filesystem (FS) failure (HDD). In that case try to use fsck to repair FS
(if it is regular linux FS, like ext2 or ext3, for xfs there were some
other util
>> PS: I already tried with "myisamchk -r -o *.MY*", but then all datasets
>> are gone and the table is empty. :-(
>
> man myisamchk
I tried myisamchk already. But after running the above rescue attempt, the
tables are empty.
--
MySQL General Mailing List
For list archives: http://lists.mysql.
Hello,
yesterday my server crashed. The harddisk got corrupted, including some MySQL
table files. So MySQL can't see some of its tables, although the table files
are visible on the filesystem. Is it possible to repair the files? It's a
MySQL 4.1 (Debian Sarge).
From one table I only have the M
Hi,
I am doing this thru the phpmyadmin interface:
ALTER TABLE doc ALTER docts SET DEFAULT CURRENT_TIMESTAMP
However, it returns #1064 - You have an error in your SQL syntax near
'DEFAULTCURRENT_TIMESTAMP' at line 1
As you can see the error shows that DEFAULT an CURRENT_TIMESTAMP ha
For best performance, you would want to have all your indexes stored
in RAM, certainly. Generally true of databases.
However, you do not have to have enough RAM to keep the indexes loaded.
You can configure MySQL to use as much RAM as is appropriate for your
machine. The online manual has som
- Original Message -
From: "Karel W. Dingeldey" <[EMAIL PROTECTED]>
To:
Sent: Sunday, August 27, 2006 6:57 PM
Subject: Re: confirm subscribe to mysql@lists.mysql.com
Am Sonntag, 27. August 2006 15:23 schrieb [EMAIL PROTECTED]:
To confirm that you would like
[EMAIL PROTECTED]
ad
Am Sonntag, 27. August 2006 15:23 schrieb [EMAIL PROTECTED]:
> To confirm that you would like
>
> [EMAIL PROTECTED]
>
> added to the mysql mailing list, please click on
> the following link:
>
>
> http://lists.mysql.com/s/mysql/44f19ce8d8f3f021/karel.dingeldey=criena.net
>
> This confirmation s
This is the first time I try to use MySQL for very large tables.
Experienced users warned me against possible problems with *index*
definition for large tables:
they claim MySQL indices are stored completely in memory, which is
problematic to me : I have a huge table and limited memory size (RAM)
19 matches
Mail list logo
