alter table alter column weirdness

DATABASE

    Sponsored Links

    Next

  • 1. [Info-ingres] Remote connection string example?
    At 10:26 AM -0700 7/18/2006, XXXX@XXXXX.COM wrote: >I'm using two different versions of Ingres between my client and server >and I'm failing on authentication using sql. I wonder if the versions >can talk this way? My Linux client is Red Hat running Ingres II 9.0.4 >and the Solaris box (my server) is running II 2.6/0305 > >On the Solaris box (server), I've created the vnode using netutil and >tested it, and it worked. However, I can't get the vnode to pass a test >on the Red Hat box. Solaris uses shadow passwords. On the Solaris box, do an ingprenv and make sure you have II_SHADOW_PWD defined. If not, define it ingsetenv II_SHADOW_PWD $II_SYSTEM/ingres/bin/ingvalidpw and look in $II_SYSTEM/ingres/files/iipwd for an iipwd.dis (I think that's what it is called), copy that to ../../bin/invgalidpw, and make sure that ingvalidpw is owned by root with permissions 4711 (setuid root). The source for ingvalidpw is in that iipwd directory as well, in case you need or want to compile setuid-root programs yourself. Once that's all done, your authorization errors ought to disappear. Karl
  • 2. Model Driven Architecture, bussiness rules in DB?
    Hey all, I'm currently involved in the development of an application framework using model driven architecture. You basically model your domain, the tool generates a DB schema with foreign keys and all, and out comes a ready-to-roll web application. The issue of usability (or lack thereof) of said one-size-fits-all Web-UI aside, all additional business rules that aren't covered by foreign keys are hand-crafted using rules and dbprocs. These non-covered bussiness rules are of course the majority of the lot, covering complex cross-table constraints, and a rather complex role-and-status-based row-and-columns authorization schema. This yields loads and loads of non-debuggable hand-coded stuff in the DB, which kind of contradicts the idea that a nearly-ready-to-run application yields from a model. I'm beginning to feel that maybe these fine-grained and complex controls and access rights really have no bussiness living in the DB, but could rather be an additional access layer on top of the DB. At this level it seems to me it would be easier to develop, debug and unit test that layer. Thoughts? -- Emiliano

Re: alter table alter column weirdness

Postby simonl » Thu, 02 Aug 2007 20:49:01 GMT



Isn't that an erroneous statement?  Not sure if not default and with
null have ever been able to co-exist.  If R3 accepted it, that would
be a bug in R3.


Re: alter table alter column weirdness

Postby simonl » Tue, 07 Aug 2007 08:27:26 GMT

On Aug 1, 10:31 pm, Karl & Betty Schendel < XXXX@XXXXX.COM >






You are correct.  I thought it was not allowed, not sure if it has
changed somewhere along the line, but 2.6 allows it, or at least is
supposed to.


Similar Threads:

1.[Info-Ingres] alter table alter column weirdness

Hi Everyone,

I'm running II 9.0.4 (a64.lnx/105)NPTL + p12125

I have two databases, one being a test version of the other. These are 
copies of each other and both exist on the same Ingres installation.

In one table within each database I wish to change a column from not 
null to nullable. The column is not part of any key on the table, there are 
no secondary indexes on the table, there are no constraints on the 
table.

So I did:
alter table odin_postal_reply alter column dob_str varchar(20) with 
null not default;

This worked without a problem on the test version of the database. But 
fails on the production version with error:
E_US0F13 ALTER TABLE: invalid change of attributes on an ALTER 
COLUMN

I have confirmed the table has 4k page size in both, it is a journaled 
table in both databases.

Anyone got any ideas what I've done wrong?

Martin Bowes
--
Random Farscape Quote #32:
John   - I don't believe I've left a Nuclear bomb on an elevator.
Chiana - You've done worse.



<?xml  version="1.0" ?><html>
<head>
<title></title>
</head>
<body>
<div align="left"><font face="Arial"><span style="font-size:10pt">Hi Everyone,</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">I'm running II 9.0.4 (a64.lnx/105)NPTL + p12125</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">I have two databases, one being a test version of the other. These are 
copies of each other and both exist on the same Ingres installation.</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">In one table within each database I wish to change a column from not 
null to nullable. The column is not part of any key on the table, there are 
no secondary indexes on the table, there are no constraints on the 
table.</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">So I did:</span></font></div>
<div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt"><b>alter table odin_postal_reply alter column dob_str varchar(20) with 
null not default;</b></span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">This worked without a problem on the test version of the database. But 
fails on the production version with error:</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">E_US0F13 ALTER TABLE: invalid change of attributes on an ALTER 
COLUMN</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">I have confirmed the table has 4k page size in both, it is a journaled 
table in both databases.</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">Anyone got any ideas what I've done wrong?</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">Martin Bowes</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">--</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">Random Farscape Quote #32:</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">John   - I don't believe I've left a Nuclear bomb on an elevator.</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">Chiana - You've done worse.</span></font></div>
<div align="left"><br/>
</div>
<div align="left"></div>
</body>
</html>

2.alter table alter columns vs. domains

Is it feasible or practical to consider adding ALTER DOMAIN TYPE type?
(basically following the same rules as ALTER TABLE).  

I don't mind bringing down all the views before I do this, it would be
just great if you could change domains from a centralized location.
Oracle offers this feature...

Merlin 


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to  XXXX@XXXXX.COM )

3.[BUGS] ALTER TABLE table RENAME COLUMN x TO y

"Donald Fraser" < XXXX@XXXXX.COM > writes:
> When issuing the following type of command:
> ALTER TABLE table RENAME COLUMN x TO y
> The column name change is not cascading through to RULEs on a VIEW.

More specifically, INSERTs and UPDATEs contained in rules don't have
their target column names adjusted.  This is because the "resname"
fields in their targetlists contain the original column names, and
those fields are actually looked at to determine the target columns.

I think this behavior is vestigial, and we could both simplify the code
and make it RENAME-proof by using just the "resno" fields to determine
the target columns.  "resname" would then have just one purpose: to
carry the "AS" alias of targetlist entries in SELECTs.  There is already
code in ruleutils.c to allow "resname" to be overridden by the current
column name of a view (thus handling RENAME applied to the view itself),
and I don't think "resname" is user-visible in any other way.

Anyone see a problem with this plan?

I regard this as something we should fix for 7.4, mainly because if you
use --enable-cassert then the backend actually dumps core when trying to
execute the outdated rule (there are Asserts in there that notice the
resname mismatch).

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to  XXXX@XXXXX.COM  so that your
      message can get through to the mailing list cleanly

4.In-place alter table and boolean column

Hello gentlemen,

In running "ALTER TABLE bigtable ADD (yncolumn BOOLEAN)" on IDS 9.40 I
found to my surprise that the server chose to execute the slow
algorithm instead of the in-place alter I expected.  Is this normal?
The Performance Guide does not say anything special about boolean
columns and "alter table", so I thought that the new column would be
added in-place as it is of a built-in type, after all.

thanks for your insight

5.Error while adding column using ALTER TABLE

Hi,

    I get this error when trying to add a column using ALTER TABLE...

The Error is...

E_QE009D Alter Table ADD/DROP column support for pages greater than 2k
    only.


The SQL statement is...

alter table abc add column xyz varchar(100);


The table doesn't contain any data...

What does the error mean?

Thanks in advance...
Srikanth

6. [Info-Ingres] Error while adding column using ALTER TABLE

7. ALTER TABLE - add several columns

8. Alter Table Column Datatype



Return to DATABASE

 

Who is online

Users browsing this forum: No registered users and 65 guest