Axton,
Well, I can say that the 7.6.04 release for Oracle, MS SQL, and Sybase databases
does not drop and recreate any table at the DB level for any operation. Whether
that operation is to resize a column, add a column, delete a column, change the
constraints on a column, whatever you may do to a form. We do not drop and
recreate a table.
If you delete a form, we of course drop the DB table (but don't recreate it).
If you drop an attachment field, we drop the DB table.
If you turn off status history, we stop using the DB table (H table) but do not
drop it
When you delete a field or change length from less than 8000 bytes to more than
8000 bytes we may delete a column and create a new one or create a new table.
BUT, we don't drop a table and recreate it in the product.
Now, did we in the past? Yes, there were operations - like deleting a column -
that were not supported by databases back in 1990 when we first coded things.
However, as the DBs added support for these things, we updated logic to use the
new commands and stop recreating the tables.
An engineer checked the code to make sure we did not drop table for any
operation other than deleting the form in the 7.6.04 code line. I don't believe
there is any change for the listed databases between 7.5 and 7.6.04 in this
area but I didn't have them check the 7.5 code line specifically. So, I have to
go with I don't believe there is any issue with 7.5 or later vs. I have
confirmed there is not an issue for 7.6.04 or later.
NOTE: You will noticed that I did not list DB2 in the database list above. When
DB2 added the DROP COLUMN operation, the code was not updated to take advantage
of it -- an oversight. So, deleting a column in DB2 does cause the table to
be rebuilt and the original deleted. This oversight has been corrected now in
the code line and DB2 will join the list of databases were we do not drop and
recreate the table under any conditions in a future release. But, this is a
situation unique to DB2 environments.
I hope this helps,
Doug Mueller
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Axton
Sent: Monday, February 27, 2012 7:53 AM
To: [email protected]
Subject: Remedy Table Recreation
First, some background information:
It used to be the case that certain operations would trigger Remedy to
recreate a database table:
- rename existing table
- create new table with the original name
- copy the data from the renamed table to the new table
- drop the renamed table
I remember altering the precision on a decimal field would trigger
this, and I seem to also remember something with currency fields.
Now for the issue:
We have applied changes to every table in the Remedy database to
define a primary key. This primary key is used for Oracle Streams
replication to a target database. If the table is recreated, the
primary key is dropped, which can cause Streams to choke if the table
contains a large volume of data.
Now for the question:
Does anyone know of an action that a user can perform through the
Remedy clients that will cause a table to be recreated in this manner?
When I say "Remedy Clients" I am referring to Dev Studio, User Tool,
ITSM applications, mid-tier, or the Remedy API.
Relevant Environment Information:
- Oracle 11g
- ARServer 7.5
- Apps 7.5 (ITSM, CMDB, etc.)
Thanks,
Axton Grams
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
