Thanks toy for the file and for the stacktrace. Investigating it now (might take a while to get this sorted).
HEy Anton -
I’m don’t want to rush you, but could you give me an update at some polnt today as to where you are with this before you stop for the day? I know we are in drastically different time zones, and I would like to plan out my day tomorrow re: this - if it could be resolved or not.
I’ve just sent you properly generated TableDefinitions file. We’ll also try to upload the fixed build to your “Personal Downloads” folder today (it will take some time to actually build it)
up, sorry for the slight delay.
No problem, Marc. I can’t go and rebuild/upload a new server until tomorrow morning anyway. Hopefully I wont find any more bugs tomorrow!!!
Thanks a lot.
One problem this morning…
The generated Table definitions file uses the single-character not-equal symbol ( ≠ ) and Oxygene complained about every occurance. I did a simple find/replace and it compiled fine.
OK, there still seems to be some issues that are being caused by what I assume is a new codegen format?
Check out this exception:
System.InvalidOperationException The operands for operator 'GreaterThanOrEqual' do not match the parameters of method 'op_GreaterThanOrEqual'.
All that changed was the version of the DA server and the client lib. This is the DALINQ code that is causing that…
HistMain := (from apr in fDataModule.DataAdapter.GetTable<lpv8oelib.Data.aprecon> where ((apr.StartDateTime >= d1) and (apr.StartDateTime <= d2)) where (apr.PostDateTime<>0) select apr).ToList;
The issue seems to be comparing DOUBLES or DECIMALS with their NULLABLE counterparts.
Should we be getting this error?
At this point there is no difference which exactly tool did generate the code. The string “
System.Nullable<System.Double>” will mean the same regardless which exactly tool did produce it (was it CodeGen or CodeDOM)
Which exactly Elements version do you use?
I’m using Elements v10.0.0.2285.
My point is that in v9.4 of DA, my DALINQ code ran without any errors. Now, that I’ve upgraded to 9.5, everything is compiling fine, but when I run my application, and it hits that DALINQ code, I’m getting some nasty exceptions stating the above.
That code was generated by DA’s codegen to builid the table definitions unit.
Do you have the old version of the table definitions file in the source control? Could you show how the
StartDateTime field was defined there?
One other thing - this is strange…
I reverted back to the old DA service so users an do their work today while I continue on with the 9.5 version. I figured the easiest thing to do so I could test it was to load up the schema in Relativity Server, then it could run alongside the production service.
so I uploaded ver 126.96.36.1990 of relativity.exe. I also uploaded my latest daSchema file and started Relativity.
I created a new client lib project to connect to Relativity, and went to update the table defs, which worked fine. BUT…when I went to compile my relativity client, I got a truck load of errors!!
D:\dev\miller\psqllib\TableDefinitions_Miller_Data.pas(1857,5): error E51: Implementation for method "method get__Columns: System.Nullable<System.Int16>" is missing D:\dev\miller\psqllib\TableDefinitions_Miller_Data.pas(508,5): error E51: Implementation for method "method get__Columns: System.Nullable<System.Int32>" is missing D:\dev\miller\psqllib\TableDefinitions_Miller_Data.pas(1858,5): error E51: Implementation for method "method set__Columns(___value___: System.Nullable<System.Int16>)" is missing D:\dev\miller\psqllib\TableDefinitions_Miller_Data.pas(509,5): error E51: Implementation for method "method set__Columns(___value___: System.Nullable<System.Int32>)" is missing
This is completely different than the error I sent to you yesterday that you fixed. It seems relativity has a different codegen issue???
CodeGen doesn’t care about the source of the Schema is process. Still these errors are really weird. Could you send to support@ both .daSchema and generated .pas files?
Open generated file with with Notepad++ and go to
Encode in UTF-8-BOM. This should fix these errors (will be fixed in the next Beta ofc)
What about the invalid operation exception w/ LINQ?
Thanks Anton - changing the encoding fixes the compilation issues with the generated defs files.
I’m still getting the DALINQ invalid operation errors though. Any thoughts on these?
Seems to be a compiler issue (this error reproduces without Data Abstract as well).
Seems compiler threats
nullable Boolean differently (despite that on IL level this is exactly the same type)
Still let me check if I can provide a workaround here
I wasn’t able to come up with a workaround, and was unable to get in contact with Carlo re: the compiler. I’m not sure what the weekend schedule is for RO employees…but if there is any chance that part or all of this could be resolved over the weekend, please drop me a message to let me know.
All the help this week is very much appreciated!!
Carlo is off until Tuesday, due to Monday being a holiday for him. If this is caused by
nullable Boolean, wouldn’t an easy workaround be to just replace the type name in the generated code?
As a side note, please remember that DA 9.5 is a beta release, ad as such expected to have bugs and regressions, as things are in flux and beta builds don’t get the full QA cycle. One cannot really expect weekend emergency response for beta builds…