type compatibility d3 --> d5

Trying to read a file with our d5-compiled application saved previously in our d3-compiled application is no succesful. It must be a type compatibility problem especially of packed records (used in d3-application).

I need information about all the changed types, and how to solve (or were to read about it).
SaxonAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

rwilson032697Commented:
It isn't a problem with the types changing, but the way the alignment is performed.

D3 defaults to word alignment, while D5 aligns fields in the records on 4 byte boundaries.

If the records are packed then there should not be a problem (can you post the record declaration, with the record sizes as reported by D3 and D5?)

Cheers,

Raymond.
0
SaxonAuthor Commented:
We use lots of records in d3 (some packed some not) partially deep structured. Unfortunately I don´t know how to get the record size so I will post you the samples below.

Regarding the first one it seems to help to change from record (d3) to packed record (in d5). But the values are correct only up to REASON. The first value of MTBF is wrong in this way.

type tcrashR= record
  activ : boolean;
  reason: string[255];
  MTBF, MTTR : tstatpara;
  CrInd : array[1..maxconnect] of Cardinal;
  KOEFF1, KOEFF2, KOEFF3 : Currency;
end;

type tcrash= array[1..maxcrashcount] of tcrashr;

type TAniJour = packed record
  time: cardinal;
  dd1t,dd2t: tddtyp;
  hori,vorw: boolean;
  jdd1,jdd2: string[12];
  tav1,tav2: currency;
  tco1,tco2: tcolor;
  status: tstatus;
end;

Hope you can help!
0
kretzschmarCommented:
hi all,

it should be help, to transform all recorddefintions in d3 and d5 into a packedrecorddefintion.

meikl
0
Introduction to R

R is considered the predominant language for data scientist and statisticians. Learn how to use R for your own data science projects.

SaxonAuthor Commented:
I understand, but our clients are using files created by a d3-application. We would like to provide a d5-application able to read older files. :(
0
rwilson032697Commented:
Saxon

You can use sizeof() to tell you how big a record is.

In you example above you are going to have to pack the record and  insert some fillers, like this:

type tcrashR= packed record
  activ : boolean;
  Filler1: of byte; // Align next field on word boundary
  reason: string[255];
  MTBF, MTTR : tstatpara;
  CrInd : array[1..maxconnect] of Cardinal;
  KOEFF1, KOEFF2, KOEFF3 : Currency;
end;

I can't tell if the MTBF, MTTR fields will need fillers as I don't know their size.

Do you see what is happening? We need to recreate the word alignment of the record as used in D3 in the D5 environmetn where the default is dword alignment.

Cheers,

Raymond.
0
rwilson032697Commented:
I thought you were able to set word alinment in D5, but I can't sem to find it in the helkp. Would be the best solution for you.

Cheers,

Raymond.
0
SaxonAuthor Commented:
The record has a size of 8868 in d3 and a size of 9248 in d5. I don´t understand how it should help to insert additional bytes. In this way I will not get equal sizes for d3 and d5 because I can influence only d5 (or I´m wrong anywhere?).

Alignment I can influence by using {$A+} / {$A-}. But this way shows effect for the whole record, and you know that we used the packed mode partially only. We don´t have a good idea to use this compiler option.

Could you comment this to points again, please?

Anyway I tried your way and it helps for some values. So we are going to spend a lot of time to explore were all these bytes are necessary. The Borland support is ingredible unfit, there is only a note like: perhaps you could have compatibility problems! And we couldn´t find a TI-doc supporting this change over.

Thank you for your efforts!
0
rwilson032697Commented:
To be able to do this correctly you need to understand how this all works.

In your D3 app, a packed record should behave the same in the D5 app (you can easily check this by checking the sizes in D3 and D5 for a packed record).

For a record that is not packed in D3, you will need to do these steps to get the correct field alignment in the records for D5:

1. Declare the record as packed. This has the effect of byte aligning all records from their default word alignment in D3.

2. Insert filler bytes after all fields (except the last one!) where the field size is an odd number:

eg:
type
D3_fred = record
         a : byte;
         b : word; // b is word aligned (ie: there is an unsed byte between a and b)
end;

D5_fred = record
         a : byte;
         filler : byte; // make b word aligned
         b : word;
end;

Do you see how this works? You will need to check each one of your non packed record types to makesure each individual field aligns correctly. In all cases checking the sizes of the D3 and D5 records should help confirm you have done it correctly.

As a general rule, any record strusture stored in a file should be packed.

There may also be issues in arrays where delphi may align records on word/dword boundaries in the array so any code which relies on byte record alignment in arrays should be checked.

Cheers,

Raymond.
0
SaxonAuthor Commented:
Below is shown our d3 structure.

type distribution=(con,uni,gau,log,exo,erl,gam);

type tstandard=record
  W: Currency;
  E: byte;
end;

type tstatpara=record
  D: tdistribution;
  P1, P2, P3 : tstandard;
end;

type tcrashR=record
  activeC : boolean;
  reason: string[255];
  MTBF, MTTR : tstatpara;
  CrInd : array[1..maxconnect] of Cardinal;
  KOEFF1, KOEFF2, KOEFF3 : Currency;
end;

type tcrash=array[1..maxcrashcount] of tcrashR;

Let´s say we saved tcrash in a file (d3). Trying to read this file from d5, the first wrong value is activeC.

Inserting packed in tcrashR, tstatpara and tstandard delivers the first wrong value at D.

After that we inserted as following:
type tstatpara=packed ...
delta: array [1..3] of byte;
D: ...

type tstandard=packed ...
delta: array [1..3] of byte;
W: ...

The values are ok up to MTTR in this case.

We understand your rules, but as you see we had to insert three bytes (one is not sufficient). (We also tried to insert one byte after activeC. In this case reason will be wrong.)

It´s a extensive conversation, therefore: 100 -> 200 ;-)

0
kretzschmarCommented:
hi saxon,
would it not be easier to code a d3-migration tool, which transform the records into packed records ?
meikl
0
SaxonAuthor Commented:
Right, that´s the point I want to explore. Unfortunately, we don´t have the best expiriences with our customers in such a way. In future it seems to be the best way to use the database capabilities of delphi for saving our data (But it´s a new area for us).
0
rwilson032697Commented:
Well, there's something very weird going on here. You should never need to insert packing before the first field in a record.

Cheers,

Raymond.
0
SaxonAuthor Commented:
Sorry, I don´t understand! In d3 it´s done and impossible to change. And in d5 I must insert packed (and additional bytes) to be able to read the old file. What do you mean with: You should never ... ???
0
rwilson032697Commented:
>What do you mean with: You should never ... ???

What I mean is that the first field in a record ALWAYS begins on the first byte of the record. This is because the record itself is aligned on a word or dword boundary.

>And in d5 I must insert packed (and additional bytes) to be able to read the old file

Its not so much as matter of inserting extra bytes, but recreating the alignment of the fields in the record so the records look the same in memory.

A packed record should look the same in D3 as in D5 (you should confirm this...)

A non packed record will often be bigger in D5 than in D3. So in order to get the alignment right we need to pack these records (to remove all the unused bytes that D3 would have put in) and then add unused filler bytes so D5 treats them the same as D3 (ie: the fields line up on the same word boundaries as they did in D3).

Cheers,

Raymond.

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SaxonAuthor Commented:
Ok, Raymond, many thanks for your help and your efforts. Now we understand our problem and we are going to fix it.

cu next time ;)
Lutz
0
rwilson032697Commented:
Thank you Lutz.

Let me know how you go.

Cheers,

Raymond.
0
SaxonAuthor Commented:
Hi Raymond,

the prob above is fixed absolutely. 90% trough your support and the remaining 10% by trial & error. Some things are mystical, i.e. we had to insert 1 to 3 bytes (perhaps, because our d3 records were only partially packed). The number of bytes matches now, and all our files are loaded succesful.

Many thanks again and hope to see you in case of our next prob again ;-)

Lutz
0
rwilson032697Commented:
Glad I could help!

Cheers,

Raymond.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Delphi

From novice to tech pro — start learning today.