Message-Id: <199804271211.VAA24591@mustang.sdc.com.au>
To: Sbragion Denis <infotecn@tin.it>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] VB and ODBC: found 
In-reply-to: Your message of "Mon, 27 Apr 1998 12:08:50 +0200."
	<3.0.5.32.19980427120850.007e6320@MBox.InfoTecna.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 27 Apr 1998 21:41:18 +0930
From: Stephen Davies <scldad@sdc.com.au>

> Hello,
> 
> after a fast look I found a reference in the MS knowledge base:
> 
> http://support.microsoft.com/support/kb/articles/q109/8/00.asp
> 
> little excerpt:
> 
> Before you can edit an external ODBC table, the table must contain a unique
> index. If you get the following error message, you might not have a unique
> index on the table: 
> 
>    Can't perform operation; it is illegal.
> 
> You could also receive this error if the Data1.Recordset.Updatable flag is
> not set to True. Also, if you set the Data1.Options property to 64
> (SQL_PASSTHROUGH), the data control will not be updatable. 
> 
OK. Maybe that is the difference. I never use data controls to access ODBC 
databases: the performance is awful.

There also seem to be strange constraints placed by MS on some types of 
recordsets: the "safest" seem to be tables rather than dynasets etc.

I always use direct calls to the ODBC DLL. This is quite easy and, in general, 
gives performance comparable with native SQL commands - and does not require 
unique indexes or other strange MS policies..

Having said that, my personal preference is to have a unique key in every 
table and if there is no obvious candidate, to make that key a 
system-generated sequence number.

Cheers,
Stephen.
========================================================================
Stephen Davies Consulting	    		                            scldad@sdc.com.au
Adelaide, South Australia.     			                            Voice: 61-8-82728863
Computing & Network solutions.	 	                            Fax: 61-8-82741015