The solution I found for the same problem was arithmetic subtraction between
unix_timestamp() values.
Hope this helps.
Bogdan
Alex Kirk wrote:
> I've been looking through the manual at www.mysql.com all of the time/date
> functions, and I can't seem to find the one I want: one that will take t
You may try this and see if it works (didn't test it, just jotted it down
here):
select t1.textid, t1.textid, t1.textvalue
from texts as t1, texts as t2
where
(t1.languageid='$Primlanguage' and t1.textid=t2.textid) or
(t1.textid=t2.textid and t2.languageid='$Seclanguage' and
t2.lan
Stig Nørgaard Jepsen wrote:
> > You may try this and see if it works (didn't test it, just jotted it down
> > here):
> >
> > select t1.textid, t1.textid, t1.textvalue
> I just don't understand why you did this?
> Why select t1.textid twice?
Ugh... That was a mistake -- I actually meant t1.textid
Depends on the column type -- what column type do you use for storing
the time values?
Bogdan
Alex Kirk wrote:
> Is this a bug in MySQL 3.23.37? Could it have something to do with my OS
> (OpenBSD 2.9)? Or am I doing something wrong with the statement "update
> time_worked set total = start - f
You must make sure you don't perform arithmetic differences between integer
values such as "2000" representing 8:00 pm and "1945" representing 7:45 pm
because that obviously would result in wrong values. For example 2000-1945=55,
which is arithmetically correct but not the desired result if you wa
Why don't you install a Linux box at home instead? You'd have the advantage of
learning about configuration as well, plus the ability to tweak the packages as
you please. If you have no Linux experience you can always check out Mandrake
Linux which is extremely easy to install, even in dual-boot m
Just my two cents: have you tried the following?
SELECT nev FROM hosoktest WHERE (nev = 'Pokember') OR (nev = \
'pokember');
Bogdan
Barnabas BONA wrote:
> If I execute the following select:
>SELECT nev FROM hosoktest WHERE nev = 'pokember' OR nev = \
>
You get quite a few examples with the documentation which is very good (I had
nil experience with SQL before reading the MySQL docs and had no problems
learning by it -- and I'm an learn-by-example man myself).
Plus I don't think I'm wrong if I say a Google search on "MySQL tutorial" will
return
You can usually try providing an empty -p parameter and be asked for the
password afterwards.
Bogdan
Philip Mak wrote:
> As far as I can tell, mysqlhotcopy does not provide a way of specifying
> the password anywhere other than the command line (e.g. it doesn't seem
> to read .my.cnf).
--
mysqlhotcopy -uroot -p test .
Philip Mak wrote:
> On Sun, 30 Dec 2001, Bogdan Stancescu wrote:
>
> > You can usually try providing an empty -p parameter and be asked for the
> > password afterwards.
>
> Doesn't seem to work:
>
> [mysql@lina mysql]$ mysq
Ooops! Sorry, I tested it and it doesn't work! Sorry for misleading you... ;-)
Bogdan
Bogdan Stancescu wrote:
> mysqlhotcopy -uroot -p test .
>
> Philip Mak wrote:
>
> > On Sun, 30 Dec 2001, Bogdan Stancescu wrote:
> >
> > > You can usually try providing
Did you define the columns as NOT NULL?
Bogdan
David Ayliffe wrote:
> I have created a test table with:
>
> CREATE TABLE TimeTest (
> Time1 TIMESTAMP(4),
> Time2 TIMESTAMP(8),
> Time3 TIMESTAMP(10),
> Time4 TIMESTAMP(12),
> Time5 TIMESTAMP(14));
>
> This works fine! No problemo
>
> Now ALL I a
difference!
> Any other ideas?
>
> -----Original Message-
> From: Bogdan Stancescu [mailto:[EMAIL PROTECTED]]
> Sent: 05 January 2002 00:12
> To: David Ayliffe
> Cc: 'MySQL'
> Subject: Re: OK - Simple Timestamps problem getting the better of me!
>
> Did y
I'm curious about this issue too - does the third line in your code take care
of the table structure as well?!
I'm also wondering how one could duplicate a whole database (for backup
purposes in my case).
Bogdan
Roger Baklund wrote:
> * saraswathy saras
> > how to copy table from one database
No, I mean the type of the fields. When you create a table you have to define
the field types -- char, varchar, stuff like that. Does your code take care of
that?
Thanks for the links!
Bogdan
Roger Baklund wrote:
> * Bogdan Stancescu
> > I'm curious about this issue too - does
I don't know if this is it, but
--
6.11 When Privilege Changes Take Effect
When mysqld starts, all grant table contents are read into memory and become
effective at that point.
Modifications to the grant tables that you perform using GRANT, REVOKE, or SET
PASSWORD are noticed by t
My suggestion (using a bigint and flagging the bits instead of using 40
char(1) fields) is only valid if you don't use any of those fields in WHERE
clauses in SELECT's. Not that you wouldn't be able to retrieve the entries
based on the respective field, but I don't think it would be indeed faster
I'm just guessing here, but I suppose most of the char(1) fields are y/n
fields. If that's the case you should consider using a single BIGINT and
flag those bits instead. That would considerably reduce the size of the
table on one hand and I guess it should improve things speed-wise as well.
Obvi
Hi all!
I bumped in a strange problem.
I dumped a help table (i.e. only text) into a file. The table contains two
fields: a "topic" (unique) field and a "content" field. Then performed a
"LOAD DATA INFILE" on the resulting file in a different database with
identical structure. Everything work
and everything works fine now.
Bogdan
On Friday 25 January 2002 01:56 am, Bogdan Stancescu wrote:
> Hi all!
>
> I bumped in a strange problem.
>
> I dumped a help table (i.e. only text) into a file. The table contains two
> fields: a "topic" (unique) field and a "
20 matches
Mail list logo