I am trying to update a specific field in the "Claims" table of my 2010 Access Database. I keep receiving an error message that says there are key violations. Here is the SQL:
UPDATE Claims SET Claims.LS_Name = "JPN"
WHERE (((Claims.Responsibility2)=0));
Is there any reason, based on the above code, that it is not working?
Thanks in advance!
My first guess would be that there is a unique key on Claims.LS_Name and your update hits more than one row.
OK, I ran into this issue as well in Microsoft Access and think I have ways to solve versions of this. The intermediate table may not be necessary. My experience is that autonumber is the issue so conversion to number seems to work, but you have to delete relationships for Access to allow this change.
remove all relationships to the destination table.
change from autonumber to number.
make new empty tablethatincrements starting with the next higher key https://superuser.com/questions/288087/how-do-i-set-the-first-value-of-autonumber-in-access
update/query to the tablethatincrements table instead of destination.
update/merge from tablethatincrementsto to the destination table, including new higher keys.
remake relationships
OR In certain situations. (for mine the new keys matched the old)
something like this (may not be exact steps)
remove all relationships to the destination table.
delete ID/primary key in destination
merge/update to destination
create new ID/Primary key in destination (so it can be autonumber to renumber keys)
remake relationships
Anyway my next research item is to see how to never use autoincrement and do the unique keys using other methods so relationships do not have to be removed to change from autoincrement to number.
Related
Our team has started to use AWS and one of our projects will require storing approval statuses of various recommendations in a table.
There are various things that identify a single recommendation, let's say they're : State, ApplicationDate, LocationID, and Phase. And then a bunch of attributes corresponding to the recommendation (title, volume, etc. etc.)
The use case will often require grabbing all entries for a given State and ApplicationDate (and then we will look at all the LocationId and Phase items that correspond to it) for review from a UI. Items are added to the table one at a time for a given Station, ApplicationDate, LocationId, Phase and updated frequently.
A dev with a little more AWS experience mentioned we should probably use State+ApplicationDate as the partition key, and LocationId+Phase as the sort key. These two pieces combined would make the primary key. I generally understand this, but how does that work if we start getting multiple recommendations for the same primary key? I figure we either are ok with just overwriting what was previously there, OR we have to add some other attribute so we can write a recommendation for the State+ApplicationDate/LocationId+Phase multiple times and get all previous values if we need to... but that would require adding something to the primary key right? Would that be like adding some kind of unique value to the sort key? Or for example, if we need to do status and want to record different values at different statuses, would we just need to add status to the sort key?
Does this sound like a reasonable approach or should I be exploring a different NAWS offering for storing this data?
Use a time-based id property, such as a ULID or KSID. This will provide randomness to avoid overwriting data, but also provide a time-based sorting of your data when used as part of a sort key
Because the id value is random, you will want to add it to your sort key for the table or index where you perform your list operations, and reserve the pk for known values that can be specified exactly.
It sounds like the 'State' is a value that can change. You can't update an item's key attributes on the table, so it is more common to use these attributes in a key for a GSI if they are needed to list data.
Given the above, an alternative design is to use the LocationId as the pk, the random id value as the sk, and a GSI with the GSI with 'State' as the pk and the random id as the sk. Or, if you want to list the items by State -> Phase -> date, the GSI sk could be a concatenation of the Phase and id property. The above pattern gives you another list mechanism using the LocationId + timestamp of the recommendation create time.
I have two tables, SRC and TGT. I want to populate all my foreign key values in TGT from the target lookups. However, I'm getting nulls into the target. I have used all natural keys for lookup conditions. Can anyone please explain why I am seeing nulls?
For instance, I want to populate foreign key values for MPNG_ID, SESN-ID, WRKFLW-ID from lookup tables based on repository name and version number.
Did you validate if all your Join Conditions are working fine? Probably try to replicate same query in DB and check if its giving you the same result. I assume some Join might have messed up which might result in Null values. Ensure that even the spaces are in sync if you are using Varchar value.
I am using Informatica to finally write in the oracle table after performing certain logical operations on the data.
The problem is that if a certain ID was already previously processed and is present in the target table then it is not inserted again.
Please suggest a workaround.
Hi, This is because you might have same primary key in the source which is available in the target. Look into primary key columns and try loading them.
Altering your target table
alter table target_table_name drop constraint constraint name;
I have table A-Z. Table A has PK of ID, and all other tables has fields that relates to TableA's ID.
I'm being tasked to do code cleanup, and I need to change the TableA's ID from length 30 to 20. I have done for other table B-Z, together with the upgrade codeunit. But when I try to change for TableA, I get this error:
"The are changes related to the following primary key that can cause data loss in the new table. The changes cannot be handled because the TableUpgradeMode of the TableSyncSetup type function for the changed table is set to Copy, which does not copy data to the new table. To fix this issue, you must change the TableUpgradeMode option to Move, then add C/AL code to an Upgrade type function to handle new table data."
What does the error mean? Do I need to change TableA's upgrade codeunit from TableSyncSetup.Mode::Copy to ::Move? Any guidance?
I'm using Dynamics NAV 2016.
Yes, you have to change the mode to Move but you also have to create a new table which holds the data temporarily from the fields where you've reduced the field length. You also have to handle the possible data truncation issue because of the reduced field length.
But I would do this in a different way (the old way from the Upgrade Toolkits):
- Create a new table with the same field length (30), copy the field contents and clear the fields (using a codeunit)
- Change the field lengths and but choose Force when NAV is asking about the Sync Mode (because you know that there is no data in those fields - SQL can drop and recreate the columns)
- Using a second codeunit copy the data back into the reduced fields - handle the truncation
I hope it helps
Simply put, i want to create a structure that has a component MAKTX, and to have a foreign key relation with MAKT-MAKTX.
More generally i want to have a foreign key check for a field that's not part of a primary key.
I see the button "Non-key-fields/candidates", but i don't really know how to use it.
Also, i don't want to use the "key fields of a text table" relation... but i don't know if that's relevant.
Is this even a good thing that i'm trying to do? I don't see any reason why it shouldn't be possible, but you might object.
[EDIT]: I have to mention that I don't really know what I'm doing. I really just want to fill a table i created with values from another, and to make sure that those values (namely MAKTX - kind ofvalues) in my table are always values from MAKT. Suppose i do the initial filling with a SELECT statement, i want the consistency to work even if i later insert new entries manually.
So I don't know whether this makes sense or not, it just sounds to me like a good idea to have the system perform this check automatically, if possible.
Main condition for creating foreign key relation is that the field should be a primary key in your reference table. While in the table you are creating foreign key its not necessary that the field is a primary key or not. The main reason for this is that foreign key cant be null.
Refer to below link for step by step process for creating foreign key relation in abap.
http://learnabaponline.blogspot.in/2013/04/how-to-create-table-in-abap.html
First off, I agree with vwegerts's comments, what you're trying to do doesn't seem to make any sense.
Perhaps this would make more sense: create your own table without the MAKTX field. Then create a database view, joining your table and the MAKT table (and set a default language in the selection conditions if you want to). This way you'll have the descriptions joined with your data, without duplicating the actual data (which is what it looks like you're trying to do).