The gdata APIs (including gcal) pretty much cram things into an ATOM feed, then authenticate to Google/publish via curl or HTTP sockets. Since the API (and Python libraries) are available from Google, it makes it fairly simple.

Yes, SELECT DISTINCT sucks. Well, SELECT DISTINCT sucks on joins and subqueries (I’m not convinced it sucks for single tables), since it tosses the query optimizer and just grabs the entirety of the table, checks it for uniqueness, then sorts it. GROUP BY works just as well in -most- instances.

The problem with the data from Access wasn’t a lack of unique keys, it was duplicate records that already had unique keys. Nothing else really worked as a constraint (since Heather sometimes had things starting or ending at the same time, or with exactly the same summary), so the DELETE FROM … WHERE EXISTS clause or a SELECT DISTINCT a INTO b seemed to be the only way to do it.

As an aside, SCOPE_IDENTITY() is T-SQL specific, and doesn’t that return the identity of the last row inserted? CURRVAL(‘id’) is pretty much the PGSQL equivalent (or NEXTVAL(‘id’). Still, though, there were only 20 duplicate keys out of 5100ish records, but nearly half those had duplicate data:

  record_id | start_time |  end_time  |           summary
-----------+------------+------------+-----------------------------
   7127485 | 1256774400 | 1256774400 | lawerance wedding
   7125815 | 1256774400 | 1256774400 | lawerance wedding

I don’t know that a unique key would have redeemed it =/ It would have been possible to generate a composite key over a couple of the fields, but composite key on a TEXT field is awful.

Foreach loop through the records. Insert individually. When inserting, use SELECT SCOPE_IDENTITY() to get a unique key.

Also, SELECT DISTINCT is an abomination before God. You do know how that works behind the scenes, right?