Gregory Machin wrote:
Hi.
I have the following table
| bid_id | dealer_id | auto_dealer_id | auto_id | bid_amount | timestamp |
Bid_Status |
+-+-+--++-++-+
| 1 |3 |
Hi.
I have the following table
| bid_id | dealer_id | auto_dealer_id | auto_id | bid_amount | timestamp |
Bid_Status |
+-+-+--++-++-+
| 1 |3 | 3 |12 |
Hi,
> How to know MySQL enable for ROLLBACK ?
Use InnoDB tables.
Martijn Tonies
Database Workbench - development tool for MySQL, and more!
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.database
Dear Sir,
How to know MySQL enable for ROLLBACK ?
Thanks you and best regards,
--
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Dear Sir,
All solutions is very good !
update TABLE1 a
INNER JOIN TABLE2 b
on a.id = b.other_id
set a.FIELD1=b.FIELD2
WHERE a.column1='literal';
Or
update TABLE1 a, TABLE2 b set a.FIELD1=b.FIELD2
where column2='[EMAIL PROTECTED]'
And column1 = '[EMAIL PROTECTED]'
Or
update TABLE1 a, T
Our mysql master machine crashed (hardware problem) and rebooted. When
it came back up, it started a new master log file. The slaves, however,
were all stuck on the last log file. They still showed both replication
threads running, no errors, but they just did not advance. I had to
manually
At 16:01 -0600 3/16/06, Sterling Anderson wrote:
On Mar 16, 2006, at 3:49 PM, Paul DuBois wrote:
This fails however. 'g/dl' != 'g/dL' though. I don't get why a
string field is being treated this way. I understand the HFS+
filesystem is not case sensitive but that shouldn't be an issued
with v
On Mar 16, 2006, at 3:49 PM, Paul DuBois wrote:
This fails however. 'g/dl' != 'g/dL' though. I don't get why a
string field is being treated this way. I understand the HFS+
filesystem is not case sensitive but that shouldn't be an issued
with varchar fields should it?
No, it's not a file
At 15:22 -0600 3/16/06, Sterling Anderson wrote:
I'm running MySQL 5.0.18 on OS X 10.4.5, on an intel MacBook. My
table definition is:
CREATE TABLE `UNIT` (
`UNIT_ID` int(11) NOT NULL auto_increment,
`UNIT_CODE` varchar(50) default NULL,
`UNIT_DESC` varchar(50) default NULL,
`USER_ID` i
I got an error 1025 trying to rename an InnoDB table. When I go to
look in the database now, that table isn't there even though there is
a .ibd file in the mysql data directory with the target name. If I
try to create a table with the target name (as an InnoDB table), I
get error 1005. I ca
I'm running MySQL 5.0.18 on OS X 10.4.5, on an intel MacBook. My
table definition is:
CREATE TABLE `UNIT` (
`UNIT_ID` int(11) NOT NULL auto_increment,
`UNIT_CODE` varchar(50) default NULL,
`UNIT_DESC` varchar(50) default NULL,
`USER_ID` int(11) NOT NULL,
`USER_DT` datetime NOT NULL,
Hi!
- Original Message -
From: ""Martijn Tonies"" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Thursday, March 16, 2006 8:59 PM
Subject: Re: NULL columns
When doing an insert using NULL in the insert request,
what really is being written in the column?
Is the wor
> When doing an insert using NULL in the insert request,
> what really is being written in the column?
> Is the word NULL being written?
> Is any real space being consumed?
In the cases that you really want to store NULL ;-)
No, it's not the word "null".
Of course space is consumed.
How m
When doing an insert using NULL in the insert request,
what really is being written in the column?
Is the word NULL being written?
Is any real space being consumed?
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PRO
I need some help with improving INSERT performance. I am using JDBC. I
have minimized my indices as much as I can, changed to use batching, and
setup a thread pool for each transacted batch. Note that I am only using
InnoDB.
Now I am wondering what can be tweaked in the server properties. Right
no
Hi,
I'm trying to see what speed I will get from a simple query like:
select * from
and I noticed the server-> client transfer is always 512 bytes.
(iostat tells me I read 6348.80*1024 bytes/sec in a given time
period, and 12697.60 reads/sec, which translates to exactly 512)
I set the max_al
The fact that I use JOTM with Tomcat forces me to use a different data
source factory from the one described in the MySQL document "Using
Connector/J with Tomcat",
(http://dev.mysql.com/doc/refman/4.1/en/cj-tomcat-config.html) -
org.objectweb.jndi.DataSourceFactory vs.
org.apache.commons.dbcp
AAAUUUGGGHHH!!! You used the dreaded "comma separated list" !!! ;-)
A more explicit way to write the same thing posted by Sr. Cruz...
update TABLE1 a
INNER JOIN TABLE2 b
on a.id = b.other_id
set a.FIELD1=b.FIELD2
WHERE a.column1='literal';
Actually posting a real query (instead of a cl
update TABLE1 a, TABLE2 b set a.FIELD1=b.FIELD2
where column2='[EMAIL PROTECTED]'
And column1 = '[EMAIL PROTECTED]'
Or:
update TABLE1 a, TABLE2 b set a.FIELD1=b.FIELD2
where b.column2=a.column1
And column1 = '[EMAIL PROTECTED]'
Regards!
-Mensaje original-
De: Truong Tan Son [mailto:
Hello Gordon,
> And now we are down to reality. This is a MySQL list. Views are a
wonderful
> thing for creating an isolation layer between the application and the
> database. However, MySQL's current implementation makes it extremely
> difficult in many cases to avoid full table scans when you de
And now we are down to reality. This is a MySQL list. Views are a wonderful
thing for creating an isolation layer between the application and the
database. However, MySQL's current implementation makes it extremely
difficult in many cases to avoid full table scans when you define the
logical view.
RedRed!com IT Department wrote:
So, for my peace of mind, I would need to follow these procedures to
ensure Martijn's issue doesn't happen:
1. lock the table
2. execute my select
3. insert if it does not already exist
4. unlock the table
On a high level, is this a correct list of procedure
> >> > Read the literature on how to design databases. What you do
> >> > is storing "true propositions". That is, each attribute defines a
> >> > certain "true proposition". For example:
> >> >
> >> > Employee "Martijn" has Employee# 14.
> >> >
> >> > You should be able to derive these sentences f
James,
> Also, surely if you left join to a table then if there's no matching row
you get a null value in your result set. So I'm not sure what the difference
is between getting that null because you store it in a column in the primary
table, and deriving it by left joining to a related table wit
Also, surely if you left join to a table then if there's no matching row you
get a null value in your result set. So I'm not sure what the difference is
between getting that null because you store it in a column in the primary
table, and deriving it by left joining to a related table with no mat
> > > in order to retrieve all the information about them. Replacing a
> > > theoretically ugly null flag with a 10 way join strikes me, as an
> engineer
> > > rather than a theoretician, the wrong side of the
> elegance/practicality
> > > trade-off.
> >
> > Using NULLs as well as de-normalization
"Martijn Tonies" <[EMAIL PROTECTED]> wrote on 16/03/2006 11:32:45:
> From: <[EMAIL PROTECTED]>
> > "Martijn Tonies" <[EMAIL PROTECTED]> wrote on 16/03/2006 11:02:32:
> >
> > > Well, the question still is if you should store "unknown" at all ;)
> > >
> > > Not according to Date: you should store wh
From: <[EMAIL PROTECTED]>
> "Martijn Tonies" <[EMAIL PROTECTED]> wrote on 16/03/2006 11:02:32:
>
> > Well, the question still is if you should store "unknown" at all ;)
> >
> > Not according to Date: you should store what is known. See the remarks
> > about the "true propositions", from which relat
> > Ah well, SQL (these days) provides plenty of functions to avoid
> > the problems. Coalesce being one of them...
> >
> > How often do people write:
> >
> > (probably not valid MySQL)
> > select firstname || coalesce(middlename || ' ', ' ') || lastname
> > from ...
> >
> Your syntax isn't quite
"Martijn Tonies" <[EMAIL PROTECTED]> wrote on 16/03/2006 11:02:32:
> Well, the question still is if you should store "unknown" at all ;)
>
> Not according to Date: you should store what is known. See the remarks
> about the "true propositions", from which relational databases are
derived
> (but
> But (in at least some situations) is not appropriate to record that you
know that you don't have a value?
>
Sure it would. It it's needed.
But the answer doesn't have to be a NULL. Remember
the example about recording the fact that a student did
not make a test for whatever reason?
It was th
But (in at least some situations) is not appropriate to record that you know
that you don't have a value?
I think the words of Donald Rumsfeld are appropriate here:
"There are known knowns. These are things we know that we know. There are known
unknowns. That is to say, there are things that we
From: "Mark Leith"
> Martijn Tonies wrote:
>
> >We're arguing about whether or not your database design
> >(as stored on disk) should contain NULLs.
> >
> >IMO: no, or at least as few as possible.
> >
> >
> I believe the answer really is - *it depends*.
>
> You are both right, really. Martijn,
Martijn Tonies wrote:
We're arguing about whether or not your database design
(as stored on disk) should contain NULLs.
IMO: no, or at least as few as possible.
I believe the answer really is - *it depends*.
You are both right, really. Martijn, yes, according to academia and
proper databa
From: "James Harvard"
> At 7:28 pm +0100 14/3/06, Martijn Tonies wrote:
> >Given that NULLs basically means the absence of a value (eg: unknown),
you shouldn't be storing NULLs.
>
> At 1:49 pm -0500 14/3/06, Rhino wrote:
> >A null means "unknown or not applicable" and is a perfectly valid value
to
35 matches
Mail list logo
