To answer your second question, because the tables
contain the accounting records of a conglomerate of
companies and for some reason the accountants insist
that they be able to browse/search through at least the
previous two months' records (which amount to a
shitload of data).
I thought of displaying just 1000 records at a time
and generate/execute a new SQL query every time the
user moves to the next/previous 1000 items myself, but
I figured there may be a more elegant way to do it... | [reply] |
OK. I've never played with mySQL (sticking to sturdy ol' Oracle) but I guess you must be able to create a cursor, and do previous/next operations to it.
Perhapps by testing for KEY_UP AND KEY_DOWN.
/t0mas
| [reply] |
Cursors are still on MySQL development team's todo list.
But in the meantime I found another, more Perlish solution:
Tie::DBI, available on CPAN. Tie a hash to an SQL table
and get table records by accessing the elements in the
hash. Obviously, there's a performance penalty, but now
my program takes up 9MB less memory. Cool.
| [reply] |