Evan Rudderow wrote:
 
>Has anyone else out there experienced a system abort 1334 caused by the
>IMAGESQL utility?  I've had two in recent weeks:
 
snip ...
 
>FYI, the IMAGESQL version is F0.25.  An S/R has been submitted for the
>anomalous DISPLAY MAP behavior and I'm now trying to get the DETACH behavior
>included in that S/R.
>
>This is so much fun!
>
>BTW, to recover the second case I *merely* purged both the TurboDB and the
>SQLDBE.  It's a good this they were both development databases -- I don't
>know what I would have done had one or both of them been production.
>
 
Like two or three others who already responded to Evan's post, I've had no
trouble with the G release.  I  went from F0.26 to G.1.08, installing G.0
only to patch forward on the same day (great faith or great folly, all this
on a production machine).  G.1 has been stable for me.  It was still in beta
when I ordered it and I'm not suggesting others should follow my example--HP
can have the call on that.  G.0 ought to improve on F0.anything, however.
F0 never crashed my system but I did once have to steel the nerves to hit
the switch to kill the power to shut down the system to abort the ODBC
connection that lived in the house that Jack built.  F0 has its problems.
 
On the subject of when to DETACH a TurboDB, and with apologies for not
posting this as a new thread: Can anyone tell me whether adding a Superdex
4.1 index, when the SI dataset already exists, counts as a "restructuring"
of the TurboDB and requires it to be detached?  Assuming it's not harmful to
build indexes on an attached TurboDB, is it at all useful, i.e. can
Image/SQL actually register a new index without an DETACH/ATTACH being done?
 Would an UPDATE STATISTICS be sufficient?
 
 
 
 
John Clark
Manager of Information Systems
The National Ballet of Canada
[log in to unmask]
Voice: 416.366.4846     Fax: 416.366.1894