Date index for Mar 2003

Hi,

Jonas Lincoln wrote:

> A dump from hours_lock gives the following result (after failed 
> conversion);
> +--------+---------------+----+
> | week   | userid        | id |
> +--------+---------------+----+
> | 200235 | sofia23       |  0 |
> | 200236 | sofia23       |  0 |
> | 200237 | sofia23       |  0 |
> | 200238 | sofia23       |  0 |
> | 200239 | sofia23       |  0 |
> | 200240 | sofia23       |  0 |
> | 200235 | administrator |  0 |
> ....
>
> Any ideas?

My fault, I should've thought of this :-(

When upgrading the locks, it adds a new primary key 'id'. Reason:

1. the userid is now a foreign key to employee.id instead of
   employee.userid (int instead of varchar)
2. Therefor, the 'all users' lock could no longer be '*', but is now
   defined as NULL for the userid.
3. The primary key of the hours_lock table was week+userid.
   Unfortunately MySQL does not accept primary keys whose value can be
   NULL.
4. Therefor, I had to add a new primary key, which is the id field.

During conversion, the field is added and set to primary key. What I 
hadn't thought of is that mysql will fail to make it primary key if it 
does not yet have a value. So the conversion script should first add the
id field, then give all a unique number and finally switch primary keys.