re probably using the RPM version or otherwise just don't have BDB
support compiled in. If you do a "show table status" you'll see that the
tables you just created with type=bdb actually are MyISAM or ISAM.
--
Tomi Junnila <[EMAIL PROTECTED]>
http://www.badzilla.net/~tope
gt;From your query I think you upgraded from a 3.22.x version? When was not a
reserved word in 3.22, but is so in 3.23. There have been a few hints how to
both circumvent and fix this in 3.23, just search the archives. The thread
was called something like "3.22 databases in 3.23 cause pr
the return value of
the call to make sure you get a proper handle, and if not, just don't try to
do anything else with mysql (or prefix all of them with @, which isn't
probably a very good idea for debugging).
--
Tomi Junnila <[EMAIL PROTECTED]>
http://www.badzilla.net/
ields, and thus MySQL must
also refer to the table.
Cardinality probably also plays an issue here, but I'll leave describing
that up to some more knowledgeable people (I can't remember that offhand and
I do need to go and eat now
has earlier been inserted into the same
table, but this insert was rolled back so the record should not be
there.
>Fix:
Not known.
>Submitter-Id:
>Originator:
>Organization:
Tomi Junnila <[EMAIL PROTECTED]>
http://www.badzilla.net/~topeju/
Elec
then search and
replace "when" with something else, and finally drop the table and run the
text file into mysql.
Another way to do this might be with "create table temporary_table ({fields
valid in 3.23}) select {fields from old table with aliases} from old_table"
but I haven'
* Santeri Paavolainen <[EMAIL PROTECTED]> wrote on 23.01.01 13:05:
> Using database created in 3.22 with a field named 'when'
> causes errors. For example,
When is a reserved word in 3.23. You're in for a nice little restructure...
(been there, done tha
* Jamie <[EMAIL PROTECTED]> wrote on 23.01.01 11:51:
> UPDATE users SET visits=visits+1, WHERE user_id='$user' AND
> password='$password'
If that comma after +1 is not a typo in the mail, then that's what's causing
the problem.
--
Tomi Junnila &
rows you received to get the
result you want.
Probably the most efficient way would be to rethink your table format to
have positive ratings as +1, neutrals as 0, and negatives as -1. Then you
could simply sum them all up without needing to subtract anything.
--
Tomi Junnila <[EMAIL PROTECTED]>
> total of the NEGATIVEs.
Err, how about
select sum(positive-negative) from rating;
?
--
Tomi Junnila <[EMAIL PROTECTED]>
http://www.badzilla.net/~topeju/
Electronics and Information Technology,
University of Turku, Finland
red as strings in
the database, and thus no rounding occurs (until you use the values
somewhere else by transforming them into floating-point values that is :-).
--
Tomi Junnila <[EMAIL PROTECTED]>
http://www.badzilla.net/~topeju/
Electronics and Information Tech
st of your query) to see how
MySQL is parsing your query, what indices it is using etc.
--
Tomi Junnila <[EMAIL PROTECTED]>
http://www.badzilla.net/~topeju/
Electronics and Information Technology,
University of Turku, Finland
--
it doesn't anymore:
create table tt (id integer) type=bdb;
show table status; # Ensure it actually is BDB
set autocommit=0;
begin;
insert into tt (id) values (55);
rollback;
select * from tt; # Earlier this didn't result in anything, nowadays it does
# have the row
13 matches
Mail list logo
