Thanks, I made this project public.
Can you please be more specific about what should I look for in this new project to answer your question above? The project is rather big (for a support ticket project) so any to-the-point instructions are welcome.
Hi Wagner,
Can you please be more specific about what should I look for in this new project to answer your question above?
There’s not really much to look at. As I understand it, “lazy loading” of the memo property Comments in TActivity (unit Form.VersionDemo_Day) causes the problem (changing to NVARCHAR[250] solves it), yet the association to a TBha (also lazy loaded) does not cause an issue.
[Association([TAssociationProp.Lazy], CascadeTypeAll - [TCascadeType.Remove])]
[JoinColumn('ID_Bha', [], 'ID')]
FBha: Proxy<TBha>;
I was just wondering how this can be explained, as I would expect similar issues.
On another note, I am also facing the same issue when I want to edit another “child entity” (TDayInfo) on the same form. Here too, editing TDayInfo, appending a TActivity and then posting the TDay causes a concurrency exception on the TDayInfo.
As you can see in unit Entities.WellDoc TDayInfo contains a couple of fields that must be memo fields as sometimes they need to hold considerable text lengths. I could declare them something like NVARCHAR[4000], but that would lead to a lot of unused space in the database (and record overflow, depending on the page size).
My current work-around is that I have now changed all these memo fields as eager loading. For example:
// [Column('Ops_Summary', [TColumnProp.Lazy])]
[Column('Ops_Summary', [ ])]
[DBTypeWideMemo]
FOps_Summary: TBlob;
Whilst this an acceptable solution (I can always “split out” memo fields in small dedicated child entities), I was wondering if you see any other solution. Is there any way to force memo fields (TBlob) to refresh as and when required in this sort of scenario?
Because even though the whole associated object is lazy-loaded, the foreign key information (the "id" of the associated object) is always known to Aurelius - otherwise it wouldn't be able to load the associated entity, of course.
Thus, since the key is known, Aurelius can already check if the FK field must be updated, even without loading the associated object.
That's not the case with blobs, because blobs don't have foreign keys, they are just data in the record itself. The only way to know if it was modified is to load the whole blob, which does not make sense performance-wise. It's better to just update the whole blob anyway.
Clear. I see the difference now. Having memos, eagerly loaded in an isolated child entity, is a good work-around for me so case closed!
Thanks again for all your patience, time and explanations!