Relativity Server question

Anton - I’m getting a new error today for some reason. What would cause my DA server to say ‘PrimaryKeyFieldCount is incorrect’? I’ve never seen this before.

Never mind. I failed to recompile my client lib…

Hello

I’ll post a long explanation to help you understand what and why causes this error (or you can just go directly to the last paragraph).

So, when a change is applied to a server client uses a Data Streamer to serialize change data. When a Delta is serialized the serializer puts to the stream the following data (besides a lot of other info):

  • Name of the Schema object
  • List of Primary Key fields

When the data is deserialized server-side the following happens:

  1. Serializer reads from stream the Schema object name and finds the corresponding object in the ServerSchema
  2. Serializer reads from stream count of primary key fields
  3. At this point serializer checks that the PK fields count in the stream matches the one in the actual Schema
  4. If these numbers do not match then the PrimaryKeyFieldCount is incorrect error is raised

So the reason of this exception is that client-side and server-side definitions of DataTable are different. Different number of primary key fields means that the server cannot apply incoming Delta without the risk of data corruption.

So please check the client and server Schema definitions (especially recent updates of the server-side Schema)

Regards

got another strange one…

rebuilt my server and client lib with yesterday’s 9.5 beta…

System.MissingMethodException 
Method not found: 'System.Nullable`1<Int32> lpv8oelib.Data.aprecbills.get_PaymentType()'.

There is a set_PaymentType in the table defs. But zero get_* methods. should there be???

Could you send your .daSchema file and generated Table Definitions file to support@. Need to take a closer look on them

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.

thanks much

Alan

Hello

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)

Thanks Anton!

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.

Alan

1 Like

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.

Alan

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.

Alan

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 9.5.0.1370 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???

Help!

Alan

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 Encoding -> 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?