I have problem with Table and Constraint name ,which are coming with version in Model Diagram representation.Using Oracle SQL Developer Data Modle shows my table name as APP_REALm_ENTRIESv4,but my table name used in create statement is APP_REALm_ENTRIES .Table name comes with extra characters v4.Because that no of time I have re-created table is four.Same problem persists with contraints too like ARE_ID_PK added with v4.
When the modeler adds "v1" or "v2" or .. on your table name your chosen table name is already defined in your model and your edited table should get the same name. To avoid that conflict the modeler adds "v1".
Related
I have created tables in Oracle DB from the SQL command line, and I'm having a problem when describing the table, when going through the oracle application express web page I can see them there.
The oracle version I have is the following:
SQL*Plus: Release 11.2.0.2.0 Production
The following is the command I used to create a table in the database:
CREATE TABLE "Product"
( "ProuctID" VARCHAR2(8) NOT NULL ENABLE,
"ProductExpiryDate" DATE,
"CustomerID" VARCHAR2(8),
CONSTRAINT "Product_PK" PRIMARY KEY ("ProductID") ENABLE
) ;
Command for describing the table:
Desc Product;
But at the end after creating each table and describe it I get this:
ORA-04043: object Product does not exist
Can anyone please tell me why I am I getting this, when I can see it in Oracle Xpress web page?
By enclosing the table name in double quotes, you created the table with a case-sensitive name. To correctly specify the name, you now have to always enclose it in double quotes.
So instead of Desc Product, you need Desc "Product".
Because this is quite cumbersome and error-prone, it's usually best to avoid enclosing table and column names in double quotes in the first place. If possible, I'd recommend you either drop & recreate the table or rename it.
I have 3 tables, "Courses"(id, start_date), "Subscriptions"(id, assistant_id, course_id, date) and "Assistants"(id, registration_date).
Subscriptions reference Courses and Assistants with foreign keys as you see.
I need to add CHECK constraint that will prevent to create Subscription record if referenced Courses.start_date is older than referenced Assistants.registration_date. Is there a way to do this in Libre Base?
Table organization could not be changed.
Such a CHECK constraint cannot be created with the default engine. From the HSQLDB 1.8 documentation:
ALTER TABLE <tablename> ADD [CONSTRAINT <constraintname>]
CHECK (<search condition>);
Adds a check constraint to the table. In the current version, a check constraint can reference only the row
being inserted or updated.
This means that commands like the following from TestSelfCheckConstraints.txt produce an error:
/*e*/CREATE TABLE TC6(A CHAR, B CHAR, C CHAR, D INT, CHECK(A IN (SELECT A FROM
TC5)));
So, to perform such a check, you will have to verify it ahead of time (or afterwards) using a query. This could be done for a form by adding a macro in the Events tab. See this post for ideas: https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=21414.
The default engine is rather old, so for such complex requirements it may be better to set up LibreOffice Base to use a different database engine. For example using MySQL, it is possible to set up a stored procedure trigger to do this kind of checking. See CHECK constraint in MySQL is not working.
Situation:
I have quite a few tables created in SQL
These tables are linked to MS Access
I can very easily "add" new entries to all but one of the tables
This table includes a Foreign key reference (but so do others)
All tables are created the same way and linked the same way
Problem:
I cannot add entries in the Spreadsheet View in Access. Generally you have some sort of entry like (where there is a * as well as empty row beneath the table you can click in and begin typing)
However this table looks like:
Right clicking on a record has "New Record" and "Delete Record" grayed out, while I can use this on other tables
I am creating the table using:
CREATE TABLE ProjectApprovers (
ProjectCode varchar(50) FOREIGN KEY REFERENCES ProjectCodes(ProjectCode),
RACFApprover varchar(50)
);
The reason I am confused is that it does not appear to be a SQL permissions problem because I can run the following code in Access:
INSERT INTO ProjectApprovers (ProjectCode,RACFApprover) VALUES ('ValidProjectCode','test123');
It seems these restrictions are only limited to the spreadsheet view. Additionally, identical syntax is used to create other tables which do not have this problem.
I am using this code to link my database tables.
Is something like this a permission problem? I have never referenced this problem table with permissions.
If Access doesn't recognize a primary key in the linked table, it will present the table as read-only in Datasheet View.
Fix this by adding a primary key in SQL Server. Then recreate the link in Access so it can notice the changed table structure.
I have a database that I migrated from MySql using SQL Server Migration Assistant and it is now stored in Azure.
SSMA apparently generated a new primary key column, named ssma$rowid, for one of the tables. I am trying to change the PK back to Card_Key, but I am getting the following error:
An error was encountered while applying the changes.
An exception occurred while executing the Transact-SQL statement:
ALTER TABLE [carddb].[Cards] ALTER COLUMN [Card_Key] INT NOT NULL.
The index 'Card_Key' is dependent on column 'Card_Key'.
ALTER TABLE ALTER COLUMN Card_Key failed because one or more objects
access this column.
How can I make Card_Key the PK again?
The easiest might be to create a new table [cards2] with the correct primary key and copy your data from [cards] into the new table (just run a INSERT INTO cards2 ... SELECT ... FROM cards). Once that's done, you can drop (or rename to [cardsold] be on the safe side) the original table [cards], and rename the new table as [cards]: sp_rename cards2, cards
This should work.
I'm trying to change the size of a column in sql server using:
ALTER TABLE [dbo].[Address]
ALTER COLUMN [Addr1] [nvarchar](80) NULL
where the length of Addr1 was originally 40.
It failed, raising this error:
The object 'Address_e' is dependent on column 'Addr1'.
ALTER TABLE ALTER COLUMN Addr1 failed because one or more objects access
this column.
I've tried to read up on it and it seems that because some views are referencing this column and it seems that SQL Server is actually trying to drop the column that raised the error.
Address_e is a view created by the previous DB Administrator.
Is there any other way I can change the size of the column?
ALTER TABLE [table_name] ALTER COLUMN [column_name] varchar(150)
The views are probably created using the WITH SCHEMABINDING option and this means they are explicitly wired up to prevent such changes. Looks like the schemabinding worked and prevented you from breaking those views, lucky day, heh? Contact your database administrator and ask him to do the change, after it asserts the impact on the database.
From MSDN:
SCHEMABINDING
Binds the view to the schema of the underlying table or tables. When
SCHEMABINDING is specified, the base
table or tables cannot be modified in
a way that would affect the view
definition. The view definition itself
must first be modified or dropped to
remove dependencies on the table that
is to be modified.
If anyone wants to "Increase the column width of the replicated table" in SQL Server 2008, then no need to change the property of "replicate_ddl=1". Simply follow below steps --
Open SSMS
Connect to Publisher database
run command -- ALTER TABLE [Table_Name] ALTER COLUMN [Column_Name] varchar(22)
It will increase the column width from varchar(x) to varchar(22) and same change you can see on subscriber (transaction got replicated). So no need to re-initialize the replication
Hope this will help all who are looking for it.
See this link
Resize or Modify a MS SQL Server Table Column with Default Constraint using T-SQL Commands
the solution for such a SQL Server problem is going to be
Dropping or disabling the DEFAULT Constraint on the table column.
Modifying the table column data type and/or data size.
Re-creating or enabling the default constraint back on the sql table column.
Bye
here is what works with the version of the program that I'm using: may work for you too.
I will just place the instruction and command that does it. class is the name of the table. you change it in the table its self with this method. not just the return on the search process.
view the table class
select * from class
change the length of the columns FacID (seen as "faci") and classnumber (seen as "classnu") to fit the whole labels.
alter table class modify facid varchar (5);
alter table class modify classnumber varchar(11);
view table again to see the difference
select * from class;
(run the command again to see the difference)
This changes the the actual table for good, but for better.
P.S. I made these instructions up as a note for the commands. This is not a test, but can help on one :)
Check the column collation. This script might change the collation to the table default. Add the current collation to the script.
You can change the size of the column in 3 steps:
Alter view Address_e and take in comment column /*Addr1*/
Run your script
ALTER TABLE [dbo].[Address]
ALTER COLUMN [Addr1] [nvarchar](80) NULL
Then again alter view Address_e, in order to uncomment column Addr1