Keytime Error Code 1001

[Darnell Rempe]

A foreign key is a column (or combination of columns) in a table whose values must match values of a column in some other table. FOREIGN KEY constraints enforce referential integrity, which essentially says that if column value A refers to column value B, then column value B must exist.

A foreign key column can reference the crdb_region column in REGIONAL BY ROW tables even if the crdb_region column is not explicitly part of a UNIQUE constraint. This is possible because crdb_region is implicitly included in every index on REGIONAL BY ROW tables as the partitioning key. This applies to whichever column is used as the partitioning column, in case a different name is used via REGIONAL BY ROW AS.

Note that allowing null values in either your foreign key or referenced columns can degrade their referential integrity, since any key with a null value is never checked against the referenced table. To avoid this, you can use a NOT NULL constraint on foreign keys when creating your tables.

By default, composite foreign keys are matched using the MATCH SIMPLE algorithm (which is the same default as PostgreSQL). MATCH FULL is available if specified. You can specify both MATCH FULL and MATCH SIMPLE.

All composite key matches defined prior to version 19.1 use the MATCH SIMPLE comparison method. If you had a composite foreign key constraint and have just upgraded to version 19.1, then check that MATCH SIMPLE works for your schema and consider replacing that foreign key constraint with a MATCH FULL one.

Unacceptable keys have any combination of both null and non-null values. In other words, MATCH FULL requires that if any column of a composite key is NULL, then all columns of the key must be NULL.

If a foreign key column has multiple constraints that reference the same column, the foreign key action that is specified by the first foreign key takes precedence. For an example, see Add multiple foreign key constraints to a single column.

The update to the referenced table returns an error because id = 1001 is referenced and the default foreign key action is enabled (ON UPDATE NO ACTION). However, id = 1234 is not referenced and can be updated.

If the default value for the customer_id column is not set, and the column does not have a NOT NULL constraint, ON UPDATE SET DEFAULT and ON DELETE SET DEFAULT actions set referenced column values to NULL.

The last statement succeeds because 1001 matches a unique id value in the customers table and a unique customer_id value in the orders table. If 1001 was in neither of the referenced columns, or in just one of them, the statement would return an error.

In the event of a DELETE or UPDATE to the referenced column (customers(id)), the action for the first foreign key specified takes precedence. In this case, that will be the default action (ON UPDATE NO ACTION ON DELETE NO ACTION) on the first foreign key constraint (fk_customers). This means that DELETEs on referenced columns will fail, even though the second foreign key constraint (fk_customer_2) is defined with the ON DELETE CASCADE action.

I'm trying to set/get the value of a property at a given frame, but I haven't found a solution that works for all frame-rates/durations/comp start times. The keyframes often end up between frames (or not exactly on the frame).

Below is sample code that I expect to work, but it doesn't. It always fails when I change the frame rate and/or compStartTime to something else than a standard 24/25fps. Same thing applies for both set/get value. In this example I set up a comp with a frame rate of 29.97 and a start-frame of 1001.

If you're working with crooked framerates you need to acount for that drop-/non-drop frame thing which I believe the the timecode functions already do, but not the normal time. So instead of using actual time, you may need to use timecode functions and retireve the time value they spit out.

For example, I created a comp with a frame rate of 24 and a start frame of 801 and duration of 100 frames. I then executed the code snippet above with a frame value of 831. The resulting keyframe is not set correctly, it's created between 831 and 832.

I can confirm that this imprecise keyframe placement thing is an issue. I've had to tackle it in many of my scripts. One solution I use is to create all the keyframes then go back through and check their timings and if they're off I remove them and replace them with one with something like a -0.0001 offset. At least that way the result of the keyframe value is being displayed on the desired frame, and if the user changes the value it will add a new keyframe at the correct time, fractionally after the scripted one, so it will corrected replace that value.

Don't think I've tried this but one idea would be to do something else like having the script trim the layer then call the Convert Expression To Keyframes function to create a correct keyframe placement you could then alter using setValueAtKey. Horribly laborious but then I've done worse to get around AE's scripting foibles!

Thanks for confirming Paul. I actually made some tests yesterday with the same method you suggested. It actually seems to work quite well. Basically, I have the script create a null object with an exporession on some property then bake that to keyframes. I can then generate a list of times for all frames. Something like this:

I see that a comp.displayStartFrame was added in 17.1 so that should be safe (haven't tested though). In earlier version it's still needed to convert the displayStartTime to frames first. I'll need to do some more tests with that and see if there are issues. If there ares issues, I guess it's possible to reset the comp start time to 0 before running the script and then reset after.

So I did some more tests, and using the "helper" approach to create a layer, bake keyframes and then read the time values on those keyframes seems quite solid. I've tested with different frame rates, different start times etc and all seems to work. It's of course a bit slower, but in my use case it's better to be slow than to fail.

Looks interesting. I've had issues though where despite using the time of an existing correctly timed keyframe it still ends up putting it in a slightly different position. You create a keyframe at a specific time, then read back that time from the keyframe and it's different to what you told it to be. This seems to happen on longer sequences.

I'm having a really hard time following the problem in this post. Keyframes are set at a time value, not a frame value. A keyframe is added at the position of the current-time indicator. If you set a keyframe at 1 second and change the framerate from 24 to 900, the keyframe will still be at 1 second.

If you have a comp that is 24 fps and you set a keyframe at frame 7 then the time will be 3.428571428571429 seconds. Change the frame rate to 30 fps and the keyframe will still be at 3.428571428571429 seconds but the frame number will be 9 because that's the closest that you can get to 3.428571428571429 seconds and have the Current Time Indicator at the start of a frame. The timing of the animation will be as accurate as it can be to the original timing given the change in frame rate. If you are animating position or rotation or anything else, the timing will be as accurate as it can be to the original timing given the start point of each frame, because nothing moves changes in a frame.

If you edit the frame value of a keyframe that happens to be not right at the start of a frame, the new keyframe will move and be lined up with the current frame. Again, there will be no difference in the timing, it will be as close as the frame rate allows it to be to the desired time. Nothing in comp will be fouled up if the keyframes do not line up with the start of the current frame.

If you start with a low frame rate, like 24, and you up the frame rate to more than double that frame rate, then you will have the ability to put a glitch in animation because there is more than one frame between the original keyframe and the new one added at the current time marker.

It also sounds like there is some confusion about how drop-frame timecode works. NO frames are ever dropped. Only frame numbers. When color was added to the television signal they had to add some additional scan lines to the signal so they had to drop the frame rate enough to include those extra scan lines. If the counter that counts frames did not skip a few numbers by the time you were up to one minute you would already be off by 2 frames. Check the time display at 29.97 fps and you will see that the clock skips from 0;00;59;29 to 0;00;01;02 so the time is as accurate to the second and only off by the frame number by a tiny fraction. One more time, no frames are missing, only frame numbers. There is no such thing as 0;00;01;00 when you have drop frame timecode.

The biggest issues I've had are with text keyframes. You might use a script to edit existing text keyframes but, even though you're telling it to replace the keyframe at the time of the existing keyframe, it gets added slightly before. In that case the edited value never gets seen. The original keyframe on the exact keyframe boundary still takes precedent. Or it gets added slightly after, so you still see the unedited text on that once frame before the change kicks in on the next.

In the case of my subtitles scripts, you're adding keyframes to a fresh layer but the keyframe ends up just fractionally after a frame boundary. If you jump to that keyframe it will actually jump to the correct keyframe boundary just before the key. Editing the text will create a new keyframe on the exact frame boundary but the original keyframe value (that still exists although there's no way to see that in the UI) will kick back in from the next frame.

This isn't related to changing frame rates. Simply that in some circumstances, seemingly with longer duration comps (as you might expect in subtitling jobs), AE's scripting flaws in being able to set a keyframe on an exact frame boundary can cause major problems. And workarounds (such as baking in all keyframes first then editing them one at a time) will introduce massive performance penalties compared to setting them all at once using valuesAtTimes, like increasing time taken from seconds to minutes.

c80f0f1006