November 2004 - main

PostgrSQL row ID column
by Chris Green 12 Nov '04

12 Nov '04

Re: my comment earlier today about PostgrSQL databases and row indentification, here's the section of the Rekall manual I remembered:- For some databases, this is always possible. For instance, in PostgreSQL every row has associated with it a unique indeitifier called the oid, which can be retrieved along with the row data; after a new row is inserted, the oid of that row can be ascertained. Similarly, Oracle has a rownum. (... and that indeitifier typo isn't mine!) -- Chris Green (chris(a)areti.co.uk) "Never ascribe to malice, that which can be explained by incompetence."

2 2

Reminder: Norwich City Gate meeting Thursday 10th November!
by adam＠thebowery.co.uk 11 Nov '04

11 Nov '04

Begin boilerplate meeting reminder txt. ------------------------------------------------- As per usual, this Thursday (10th November) we'll be congregating in the City Gate from around 8pm. Adam, Brett, Kirsten and Jonathan should be there, and Eli might also make it. We should have a penguin in attendance so you know who we are, if not look for the Linux Magazines on the tables, sometimes we lurk at the far end of the building in the restaurant area. If you want to do gpg keysigning then at least a few of us should be there with sigs and id. Full details can be found at: http://www.alug.org.uk/meetings/2004/all-NorThu.html Directions at: http://www.alug.org.uk/venues/citygate.html Pictures from August of people so you know who to look out for: http://www.earth.li/~noodles/Photos/2004-08-ALUG/ ------------------------------------------------ Adam -- jabberid = quinophex(a)jabber.earth.li AFFS || http://www.affs.org.uk/ || Not a filesystem

4 3

Adding an auto column to an existing database
by Chris Green 11 Nov '04

11 Nov '04

If I add an 'auto' column to an existing database to provide a unique key (I don't believe this should really be necessary, see below) will it get automatically populated with a sequence of integers as required? Access can manage without a unique key so why can't any of the mysql front ends do without it? I had a look at my Access database and, although the rows as a whole are unique it turns out that I *don't* have a multi-column primary key to give a unique key. However the database copes quite happily with multiple purchases of stamps with identical descriptions and with pension payments of the same amount every month. It certainly works and I can delete one pension payment without affecting the others for example. -- Chris Green (chris(a)areti.co.uk) "Never ascribe to malice, that which can be explained by incompetence."

5 9

[ALUG Announce][ALUG] Reminder: Norwich City Gate meeting Thursday 10th November!
by Brett Parker 11 Nov '04

11 Nov '04

ALUG Announce Please send announcements to Announce(a)lists.alug.org.uk Unsub, change settings via http://lists.alug.org.uk/mailman/listinfo/announce ----- As per usual, this Thursday (11th November) we'll be congregating in the City Gate from around 8pm. Adam, Brett, Kirsten and Jonathan should be there, and Eli might also make it. We should have a penguin in attendance so you know who we are, if not look for the Linux Magazines on the tables, sometimes we lurk at the far end of the building in the restaurant area. If you want to do gpg keysigning then at least a few of us should be there with sigs and id. Full details can be found at: http://www.alug.org.uk/meetings/2004/all-NorThu.html Directions at: http://www.alug.org.uk/venues/citygate.html Pictures from August of people so you know who to look out for: http://www.earth.li/~noodles/Photos/2004-08-ALUG/ -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: iDunno(a)sommitrealweird.co.uk ----- Send discussion replies to main(a)lists.alug.org.uk (Reply-To set) Unsub, change settings via http://lists.alug.org.uk/mailman/listinfo/announce

1 0

Re: [ALUG] Skype is pretty good
by Wayne Stallwood 10 Nov '04

10 Nov '04

On Tuesday 09 November 2004 12:08 pm, you wrote: > On Mon, 2004-11-08 at 23:58 +0100, Wayne Stallwood wrote: > > But my headset is evil, it digs into my ears and the sound quality is > > terrible. > > I've ordered a Sennheiser PC 155 USB today. > I'll post my experiences to the list... > > -- Martijn oooh Sennheiser, I like their kit. Got a lovely pair of their headphones plugged into my Hi-Fi downstairs, fantastic things. Didn't realise that they made computer headsets though, I'll have to check out their stuff. Let us know what happens with the PC155's when you get them. Following on from the Plantronics post I mailed their customer support, I give them 3 points for responding in a day and 2 points for even knowing what Linux is. "Wayne, Currently Plantronics has no active driver development plan for Linux. The DSP headsets have been found to work as an audio input and output device under Linux if the kernel version is 2.4.2 or higher compiled with USB support. The inline volume controls and mute switch will not work however, since these would require a compatible HID driver for Linux." I have since mailed them back asking if they would ever consider opening up the device specs so that the community can sort out Linux support for them. I am guessing that I'll either get no response or "no" but hey it's worth a shot. What with skype seeming to get some sort market penetration and having Linux support surely the momentum for things such as this to be supported must be there now.

2 1

Online calender - any suggestions?
by Dave Briggs 10 Nov '04

10 Nov '04

I am looking for an online calender for a website, largely so that I can access it from any computer wherever I am. Has anyone had a happy experience of using any such system on their sites? Google and Sourceforge reveal there are quite a few about so I thought I would fish for some recommendations before going through them all myself. While I am just after a calendering system at the moment, anythingt that offers more features than that wouldn't be a problem. I have PHP and a MySQL database to spare, so that's no problem. Thanks Dave -- Dave Briggs http://www.palimpsest.org.uk - The Home of Informed Debate on the Web

3 3

Mandrake Community is not intended to be stable...
by syd 09 Nov '04

09 Nov '04

Brief reminder/warning/explanation re Mandrake Community editions: the 'community' editions are an ongoing beta-testing exercise by the mandrake community. This is s/w that is very likely to be broken. It is not going to give an stable mandrake install. Unless you really want to be part of a beta-testing exercise - including frequent large updates- don't use the Community edition - use the major 'Official' releases. Syd

7 6

Primary keys in mysql databases
by Chris Green 09 Nov '04

09 Nov '04

Lots of the GUI front ends for mysql that I have been looking at are very insistent that the tables one uses have a unique primary key to guarantee uniqueness. I don't quite understand why this is so necessary but this isn't particularly important at the moment as the database tables I've imported have unique rows. However neither mySql nor the front-ends seem to know about unique keys made up of more than one column, is this because such a thing is regarded as a rather advanced approach or because it's actually not possible in mySql? My unique key is the combination of date (the date of the transaction) and the transaction description. This means that there can be the same transaction on different dates, e.g. if I buy some stamps on two different dates the description can be 'Stamps' for both of them. The advantage is that I am protected against entering the same transaction twice by mistake as this will transgress the unique key requirement. If I really *did* buy stamps twice on the same day then I just put 'Stamps again' or some such. The oft recommended 'Auto' column seems a bad way to do things because it doesn't prevent duplicate entries, you could inadvertently put 'Fred Bloggs' into your address book lots of times, each with a different value in the auto 'ID' column. It really seems to me that the auto column approach is a quick and dirty bodge which loses some (most?) of the advantages of a unique key and wastes space as well. Joins between tables can just as easily be done on the 'real' values as on an articifial unique key. My transaction types are held in a separate table and the join to the transactions table (when needed) is simply done with the transaction type code. This again guarantess what one wants which is that one can't enter a non-existent transaction type in the transactions table. I can see no advantage at all in having an additional, numeric, ID column in the transaction types table. Have I missed something here or is it just that the documentation I'm looking at is trying to make things 'simple' and using an auto column is the 'simple' way to do it? -- Chris Green (chris(a)areti.co.uk) "Never ascribe to malice, that which can be explained by incompetence."

4 5

Re: [ALUG] Primary keys in mysql databases
by Richard Lewis 09 Nov '04

09 Nov '04

On Tue, 9 Nov 2004 13:04:49 +0000, "Chris Green" <chris(a)areti.co.uk> said: > Lots of the GUI front ends for mysql that I have been looking at are > very insistent that the tables one uses have a unique primary key to > guarantee uniqueness. > > I don't quite understand why this is so necessary but this isn't > particularly important at the moment as the database tables I've imported > have unique rows. > > However neither mySql nor the front-ends seem to know about unique > keys made up of more than one column, is this because such a thing is > regarded as a rather advanced approach or because it's actually not > possible in mySql? > > My unique key is the combination of date (the date of the > transaction) and the transaction description. This means that there > can be the same transaction on different dates, e.g. if I buy some > stamps on two different dates the description can be 'Stamps' for both > of them. The advantage is that I am protected against entering the > same transaction twice by mistake as this will transgress the unique > key requirement. If I really *did* buy stamps twice on the same day > then I just put 'Stamps again' or some such. > You can do this: CREATE TABLE transactions (date DATE, description TEXT, ...) PRIMARY KEY(date, description) but this will still be true: SELECT date, description FROM transactions WHERE (date=...) AND (description=...) and as for updates, well you handle them using your wrapper code: e.g. in PHP $result = mysql_query("SELECT trans_id FROM transactions WHERE date=" . $_GET['date'] . " AND description LIKE " . $_GET['description'] . " LIMIT 1"); if mysql_num_rows($result) = 0 { mysql_query("INSERT transactions (date, description) VALUES (\"" . $_GET['date'] . "\", \"" . . $_GET['description'] . "\""); } else { echo "<p class=\"error\">Transaction not unique!</p>\n"; } > The oft recommended 'Auto' column seems a bad way to do things because > it doesn't prevent duplicate entries, you could inadvertently put 'Fred > Bloggs' into your address book lots of times, each with a different > value in the auto 'ID' column. It really seems to me that the auto > column approach is a quick and dirty bodge which loses some (most?) of > the advantages of a unique key and wastes space as well. > I think the point of having a field like: CREATE TABLE table (id INT NOT NULL PRIMARY KEY auto_increment, ...) is for when the other fields of your table are not necessarily going to be unique. Like an address book: none of the fields name, address, postcode, telephone etc. *have* to be unique, so an automatic unique, key column is useful, even though the value in it is unrelated to the data itself. It allows you to say things like: SELECT date, subject FROM messages, address_book WHERE (name LIKE "%smith%") AND (messages.from_id=address_book.record_id) > Joins between tables can just as easily be done on the 'real' values > as on an articifial unique key. My transaction types are held in a > separate table and the join to the transactions table (when needed) is > simply done with the transaction type code. This again guarantess what > one wants which is that one can't enter a non-existent transaction type > in the transactions table. I can see no advantage at all in having an > additional, numeric, ID column in the transaction types table. > Yes, if you can guarantee uniqueness in some meaningful field then you don't use an auto_increment field as primary key. > Have I missed something here or is it just that the documentation I'm > looking at is trying to make things 'simple' and using an auto column > is the 'simple' way to do it? > Richard -- Richard Lewis richardlewis(a)fastmail.co.uk

1 0

Re: Firefox editor
by tom potts 09 Nov '04

09 Nov '04

I've just updated to Firefox ve 1 releas and http://cuneaform.mozdev.org/editor/index.htm no longer works with it! ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0