Hiii,
I am new to axapta
I have a table in which I want two fields together should act as a primary key. Is this possible or not
If not is there any alternate way to achieve.
There are many examples in the AOT.
For example, table MarkupTrans has primary index TableRecIdIdx created from 3 fields (TransRecId, TransTableId and LineNum); table VendInvoiceInfoLine has primary index TableRefIdx created from 5 fields (TableRefId, ParmId, OrigPurchId, LineNum and RecId), etc.
Related
I am using SQLite for my web application. I have a student_id in 4 different tables using as Primary key and Secondary key as well. For example, in the student table, student_id is the primary key. In other tables, I am using student_id as the secondary key. Now I want to add the last updated row in all the tables which have student_id as one of the columns. If there is any change in any of the rows or any of the tables where the student_id exists the last updated row should get an update with the current date in all the tables. I know we have to use triggers for getting the current date if there is any change. Is there any way that I can use one trigger to update all tables base on the student_id with the current date? or any other method?
This should be an easy one. I need the SQL to insert into a table that has only one column and it is and autoincrement field.
Similar to this post but SQLite (I am new to SQLite).
Inserting rows into a table with one IDENTITY column only
create table ConnectorIDs
(
ID integer primary key AUTOINCREMENT
);
--none of the following work
INSERT INTO ConnectorIDs VALUES(DEFAULT);
INSERT ConnectorIDs DEFAULT VALUES;
Yes this is strange and if you care here is the reason, if you want to tell me a better way. I have several different item tables that all can have many-to-many links between them but sparse. Instead of having n! bridge tables, or one bridge table with a "Type" that I can't guarantee truly maps to the correct table. I will have one ConnectorID table and each item with have a connectorID key. Then I can have one bridge table.
Insert a null value:
INSERT INTO ConnectorIDs VALUES(NULL);
From the docs:
If no ROWID is specified on the insert, or if the specified ROWID has a value of NULL, then an appropriate ROWID is created automatically.
I have two tables, category (pk) and foreign key table Item(fk).
In item table have itemid, item name,category I'd....and this category I'd is foreign key column with primary table...which is having category I'd, Category name.
And I have relationship between category table as parent and. Item table as child table....category I'd is the relationship between them. When I delete records based on itemid the records should be deleted from the application but maintained at backed level..as I do not want duplicate item...even I have deleted from application.
At Application level I am doing these things with textboxes for and drop down list which should category names.
If I have got you correctly, what you want to do is, maintain the data in the database table even if you delete it from the application interface.
If that is the case, you simply can add a column like 'isDeleted' in both of the tables in the database. In the delete event, just fire the update statement instead of actually deleting the record and set the 'isDeleted' field value to 'True'. At the time of displaying data from the tables, just select the records having 'isDeleted' value equals to 'False'.
I'm trying to get to grips with indexes. Given the table:
Books
------
ID (PK)
Title
CategoryID (FK)
AuthorID (FK)
Where in my ASP.net pages, I have webpages that will fetch the books by author, or by category, would I create an index on CategoryID Asc, AuthorID asc if I wanted to improve retrieval times?
Have I correctly understood it? If I use multiple columns as above, is that called a clustered index or is that something else?
You should create two indexes, one for the CategoryID and one for the AuthorID. Having both in the same index is not what you need if you look for one or the other; you'd need that if you were always querying for both at the same time (e.g. category and author).
A clustered index controls the physical order of the data. Usually, if you have an identity column, using it as clustered index (which the primary key by default is) is just fine.
A clustered index means the data is stored in the table and on disk (etc.) in the order the index specifies. A consequence of this is, that only one clustered index can exist.
The index CategoryID Asc, AuthorID asc will make lookups on specific categories faster, and lookups on specific categories with specific authors would be ideal. But it is not ideal for author lookups alone because you will have to find authors for every category. In that case two separate indexes would be better.
The appropriate index would depends on what the query does. If you have a query joining against both category and author, then you may have use for an index with both fields, otherwise you may have more use for two separate indexes.
A clustered index is an index that decides the storage order of the records in the table, and has nothing to do with the number of fields it contains. You should already have a clustered index on the primary key, so you can't create another clustered index for that table.
I am using Visual Web Developer and Microsoft SQL server. I have a tag table "Entry_Tag" which is as follows:
entry_id
tag_id
I want to make the entry_id and tag_id pairing unique. A particular tag can only be applied to an entry once in the table. I made the two columns a primary key. They are also both foreign keys referencing the ids in their respective tables. When I dragged the tables into the Object Relationship Designer it only showed a relationship line between either "Entry_Tag" and "Entry" or when I tried again between "Entry_tag" and "Tag".
The "Entry_tag" table should have a relationship with both "Tag" and "Entry".
How do I go about doing this?
In general, you can add a unique constraint on the table that includes both columns. In this case, including both of the columns in the primary key should have already done this. If you have relationships set up for each field to other tables, then I believe those relationships should be displayed in the query designer... I see no cause for this given the information you've provided - perhaps you need to post more information.
Create an UNIQUE INDEX to for entry_id and tag_id.
CREATE UNIQUE INDEX index_name ON table (entry_id, tag_id)