Error with upgrade codeunit when changing table's PK length - microsoft-dynamics

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

Related

Soft Delete. Move records or create "deleted" column

I am a little confused about which is better for soft delete.
There are two ways for Soft Delete.
create table for deleted records.(In this way we will make copy
for the records in the table of deleted records, then delete it from its table)
create extra column called deleted,(In this way we will only change the status of this field to true , then at display records we will filter according to this extra field)
Also, I want to store the changes of the records after every update, So I think creating extra table is more suitable. What is your opinion?
I agree with #web-engineer, adding a nullable column with the datetime of when the row has been soft-deleted is the best. I used this ressource to do this.
And to answer the second part of your question, yes an extra table will be needed. There is a third party app named django-simple-history which handles it for you.
Best option is the second one, in your first example it's not a soft delete if your deleting it from the table - soft should be to modify the data in a minimal way. Leaving the row in place is the purpose of a soft-delete, this has the minimal effect on the data and will retain all attributes such as primary key index value and any internals you cant see that the database might use.
Your first option is far less succinct as it means duplicating data structures. A common approach is to add a "deleted_at" column (default to NULL), this positively identifies the record state.

Copy Records in Oracle Apex

I need to copy selected row values and store as a new record.
I am using Oracle Apex 4.2 and Tabular Form.
I need to use checkbox to select the rows and button copy. When i select multiple rows followed by click copy button to copy all the selected row values as new rows and save.
Can anyone Help
Copying Records Through an APEX Tabular Form Input
The idea of cloning existing records from a single table through an Oracle APEX Tabular Form works without much interference with the default design that you can set up through the APEX wizard for page region content.
Build a table with an independent primary key.
Suggested to include two auxiliary columns: COPY_REQUEST and COPIED_FROM for running copy operations. Specific form elements will map to these columns on the tabular form that will be set up.
Build an Oracle stored procedure that can read which records need to be copied. This procedure will be invoked each time the SUBMIT button is pressed.
(optional) Consider including a suppression of step (3) in the event that there is nothing to process (i.e., no records marked for copying).
The Working Table for Receiving Input: COPY_ME
TIP: You will have an easier time if you use the standard TABLE creation wizard. Designate CUSTOMER_ID as the PRIMARY_KEY and have APEX create its standard auto-incrementing functionality on top. (sequence plus trigger set up.)
Here's the sample data I used... though it doesn't matter. You can put in your own values and be able to verify what happened easily.
The Heavy Lifting: The Stored Procedure for Cloning Records in COPY_ME
This procedure works with 1 or more records at a time with a special identifier in the COPY_REQUEST table. After the task is done, the procedure cleans up and resets the request value again.
create or replace procedure proc_copy_me_request is
c_request_code CONSTANT char(1):= 'Y';
cursor copy_cursor is
SELECT cme.CUSTOMER_ID, cme.CUSTOMER_NAME, cme.CITY, cme.COUNTRY,
cme.COPY_REQUEST
FROM copy_me cme
WHERE cme.COPY_REQUEST = c_request_code
FOR UPDATE OF cme.COPY_REQUEST;
BEGIN
FOR i in copy_cursor LOOP
INSERT INTO copy_me (customer_name, city, country, copied_from)
VALUES (i.customer_name, i.city, i.country, i.customer_id);
UPDATE copy_me
SET copy_request = null
WHERE CURRENT OF copy_cursor;
END LOOP;
COMMIT;
END proc_copy_me_request;
There is also a column that can be hidden. It tracks where the record was originally copied from.
Note that the cursor is using the FOR UPDATE OF and WHERE CURRENT OF notation. This is important because the procedure is changing the records that are referenced by it.
APEX Page Setup Instructions
Set up a standard FORM type page and choose the TABULAR FORM style. Follow the set up instructions, taking care to map the correct primary key, and also to the PK sequence object created with the table in the previous steps above.
This is what your page set up will look like after these steps are completed:
EDIT The COPY_REQUEST Form Value:
Under the column attributes section, change the Display As option to "simple checkbox"
Under the list of values section, put a single value under the LOV Definition: Y (case sensitive in either way... just be consistent)
EDIT The COPIED_FROM Form Value:
Under the column attributes section, change the Display As option to "Display as Text(Saves State)". This is just to prevent users from stepping on this read-only field. You could also suppress it if it isn't important to know.
CREATE a New Process: Execute Copy Procedure
This is the bottom of the same configuration page, there are very few things to change or add:
Demonstration: Screenshot of COPY_ME Tabular Form Page in Action
The first screenshot below is before the page is tidied up and the checkbox control is put into place.
Plug in some test data and give it at try. The Page Process created in the step above conditionally invokes the stored procedure that processes all copy requests made at the same time when the SUBMIT form button is selected.
COMMENTS: If you spend enough time tinkering around with the built-in wizards in Oracle APEX, there are opportunities to learn new design patterns and process flows compatible within the tool. Adapting your approach can reduce the amount of additional work and frustration.

Update Query Will Not Work Due To Key Violations

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.

I have a field in APEX set with a default of SYSDATE but it does not update

I have a field defined in my table as DATE and want it to automatically populate with the current system date when someone access the update form in my APEX application. But the date doesn't update. It was working when I first added it, but now when you pull up the update page it only shows the date that's in the table.
In Oracle, a default on a column means that if a record is inserted into the table without mentioning that field, then use the default. My guess is that since the field is displayed on your page, you are writing NULL or spaces to it, so it is definitely included in the insert statement.
So you need to either take it off the page, add an update trigger, or even better, write a process in Apex to update it whenever the record is modified -- perhaps an After-Submit computation.

Oracle APEX - Setting up a Tabular Form with default values

I pretty new to APEX and I'm having a bit of trouble working with my first Tabular form. The table I've linked it to is fairly simple. The columns are as follows:
Primary key representing an internal
code for a college major
Foreign key representing the "real"
code for the college major
Description for the college major
The user that inserted/updated the
row in the table
The date the row was inserted/updated
At the moment, I'm facing two problems.
I want the user to be able to specify their own primary key for the row but not to be able to change any existing primary keys. When I specify the column type as "Text Field" users are able to edit existing rows' primary keys and it also seems to break the report when trying to add a new row as I get a checksum error.
I would like the user and date
columns to default to the currently
logged in user and the current date,
but specifying default values for
either of these columns also seems
to cause syntax/SQL errors. Does
anyone have any examples of how to
use the default value functionality
for a column? Fixed. I can just use SYSDATE as a value on it's own when specifying the PL/SQL type for default. Username can be obtained through functions in APEX_UTIL
Perhaps you could use 2 conditional fields. If the field value is null, display the edit box, if the field value is not null display the display-only field.