Alas, the decision to not store information about local temporary tables in the system catalog was made a long time ago in a galaxy far, far away.
One side effect is this sentence in the Help: "You cannot use ALTER TABLE on a local temporary table."
Was it a good decision? If it contributed to the great speed of temp tables in SQL Anywhere, then yes, I think so.
Does that decision cause great pain? Oh, yes... from time to time... but there has not been much hue and cry over the years. Not nearly as much anguish as with other products; e.g., endless debates and discussions of the tempdb database in [this other product] and [that one].
Would it be difficult to change? Oh, gosh, I do think it would fall into the category of "changing basic architecture"... I recently had to do one of those kinds of changes, in Foxhound, not something you consider lightly :)
But... you're just asking for ALTER TABLE to work on local temporary tables. In theory, you could implement that without storing information in the catalog. In theory.
answered
12 Mar '10, 19:56
Breck Carter
32.5k●540●724●1050
accept rate:
20%
One brute force workaround is to copy-and-edit the CREATE TABLE displayed by Foxhound or produced by dbunload. Not nearly as maintainable as SELECT * which does not have to be edited when the schema changes. Folks have asked, in the past, for the ability to "create this new table to look like that one", possibly in the old product futures discussion newsgroup.
@Breck: I guess the even easier "brute force" method would be to use Sybase Central to mark the table and copy its schema. That needs just a few clicks/shortcuts:)