I know the first key is Shift, and what is the next key?
Related
In my installation of Ultraedit, the delete key does the same as the backspace key. That is, it deletes to the left. How do you make the delete key delete to the right? Or what other way can that be done?
I'm trying to pass a primary key value to another page in Oracle Apex Cloud. The problem here is that the Primary Key is generated using triggers.
When I used Oracle's Apex feature set Item in branches to send in the primary key to the next page, it didn't work and caused an error because it was trying to read data from the hidden Item ( Primary Key ) in the first page which is null because the primary key is only generated after an INSERT action so the Primary Key in the form will remain empty which means I can't retrieve it using Oracle's Apex set Item feature. So I want to send the primary key that is generated after the Form has been submitted to the next Form/Page.
I've searched around for a workaround this problem but can't seem to figure it out myself. I saw a method using "Return Key as Item" to send in the primary key to the next page but the explanation wasn't really detailed ( at the very least to me ) so I don't even know where to start or how to do it.
You don't explain what process is creating the primary key, so I'm doing a bit of guessing here:
I'm assuming that this a region of type form that creates the row with a new primary key value. I created a region on the DEPT sample table with primary key item P1_DEPTNO
By setting the attribute "Return Primary Key after Insert" the item P1_DEPTNO will get the primary key value of the row that has been inserted and can then be passed on to another page.
You commented you're still getting an error (didn't specify which one, though).
Anyway: create a page process (let's call it GetPK) which looks like this:
:P1_ID := nvl(:P1_ID, sequence_name.nextval);
Doing so, you'll put the primary key value into :P1_ID item. Now you can use it in branch to another page and set :P2_ID to :P1_ID.
That's how it usually goes and it works OK.
How would you go about fixing an existing a year database that uses a composite key from the fields school and year that no longer represent a unique row? One of these schools are releasing a biannual yearbook. Should I just generate an id and use that for the primary key?
I suggest adding a semester or term field. You could just create a surrogate key, but adding another field to your composite key gives you the flexibility to handle quarters/semesters neatly.
On a weekly basis I would like to export from a test database into a production database once the data has been reviewed.
I've been using the following action queury:
Sub testCopyFromTestDB()
Dim digitalDisplaySQL As String
Dim SEMSQL As String
SEMSQL = "INSERT INTO [tblSEMMetricsAdGroups] IN 'C:\DestinationDatabase.accdb'" & _
"SELECT [TESTtblSEMMetricsAdGroups].*" & _
"FROM [TESTtblSEMMetricsAdGroups]" & _
"WHERE [TESTtblSEMMetricsAdGroups].[startDate]=#08/19/2014#;"
DoCmd.RunSQL SEMSQL
End Sub
However, recently all of my records do not append due to duplicate primary keys. The primary keys for both fields are AutoNumbered. I understand the issue is the duplicate keys what I'm struggling with is sensible solution to resolve this error going forward.
It should be noted that these records do not have another field that can serve as a primary key.
Any suggestions?
Thanks in advance,
Chris
If you have autonumbered primary keys, you should not normally be supplying a value. That's the whole point of autonumbering. If the value of the primary key has independent meaning, like the value of the primary key on table A is supposed to be the same as the value of the primary key on table B, than don't use autonumbering, because it won't work. Don't try to use a hammer to put in screws and don't try to use a screwdriver to put in nails. :-)
The whole concept of a Primary Key is to give your record a field that makes that record absolutely, positively unique. If an AutoNumber field can not do that, then an AutoNumber field is not the proper Primary Key. This is cut and dry, and indisputable.
You are going to need to change your Primary Key to something that is unique and not duplicable. Going forward, you should make your Primary Key a combination of your AutoNumber field, concatenated with the numeric value of your Date Entered field (assuming you have one, or something similar).
Alternatively, you can just import everything but the primary Key, unless you've got other tables that are related in some way and need the key to link them together.
I have a problem, the database admin have the follow structure:
As you can see the primary key of the table TCModulo is a composed key of the ID_modulo and ID_sistema which is a foreign key of the table TCSistemas.
I think that is better that the field ID_modulo from the table TCModulo must be the primary key with an auto_increment constrain, and the field ID_sistema must be only a foreign key.
Wich one is better?
Whether the PK of TCmodulo is (ID_modulo) or (ID_modulo,ID_sistema) depends on what goes in the table. We cannot answer your question unless you tell us. Presumably an ID_modulo value in a row is how you refer to some modulo. You have to tell us how to do that. But after that (for every column) (and given what situations can arise) there is no choice left about which sets of columns are candidates for primary key.
A set of columns whose subrow values are unique in a table is called a superkey. Any subrow containing a unique subrow is unique. So any set of columns containing a superkey is a superkey. A subrow that contains no (smaller) unique subrow is called a candidate key. So a superkey that contains no (smaller) superkey is a candidate key. One of the candidate keys of a table is chosen as primary key.
If ID_modulo uniquely determined a module over the whole application, then (ID_modulo) would be unique with no smaller unique subrow inside so it would be a candidate key. It would be the only one so it would be the primary key.
If ID_modulo uniquely determined a module only per sistema, then (ID_modulo,ID_sistema) would be unique with no smaller unique subrow (assuming there can more than one sistemo) so it would be a candidate key. It would be the only one so it would be the primary key.
So what candidate keys are available to be chosen as primary key is up to how your application refers to modulos. After that there is no choice about candidate keys. In each of these two cases there's only one candidate key so there's no choice about primary key either.
As to whether you should have a unique id overall or only within sistema or both or anything else, that depends on other ergonomic issues. Eg you are uniquely kentverger in stackoverflow (now; user names aren't necessarily unique), but perhaps uniquely Kent at home. Eg you probably prefer to call today something like the 4th of July, rather than day 185. But note that any candidate key serves as a unique identifier. So if ID_modulo is unique only within sistema, still (ID_modula,ID_sistema) is unique overall.
Note that this has nothing to do with modulos being many-to-one with sistemas per se. It has to do with columns forming unique subrows.
I always prefer to use an identity (auto-increment) for the primary key, as it keeps the pages clustered better and avoids fragmentation on the disk. You need a foreign key ID_sistema anyway, so add that too.