[DUG] Validating CDS files

[Alister Christie]

It might be best to ask on stackoverflow at this point.

 From looking at the code for LoadFrom and SaveTo Stream it doesn't look 
like there is any information that you can use to validate the file 
format easily.

You are probably stuck with loading the .cds file to validate it.

Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
PO Box 13085
Johnsonville
Wellington


On 17/01/2011 1:29 p.m., Matthew Comb wrote:
> Hi Jolyon,
>
> Everything you say is right. I could bore you with how our smart client
> architecture works , how much data we're pushing and what happens at each
> point, but at the end of the day, it all will end up back to the beginning
> which is the need to know the state of a binary CDS file before load.
>
> In short though, the software will always retrieve from server a CDS
> dataset if it does not exist on disk.
>
> So if we attempt to load a CDS set, and its corrupt, desired approach is
> to delete the file, and refetch from server.
>
> I'd like to be able to do that without having already loaded corrupt data
> into the application clientdatasets which would be resorting to damage
> control, rather than a clean delete and refetch.
>
> Matt.
>
>>> What I'm really after is a file level test to check that file should
>>> even
>>> be attempted. e.g. open file stream seek start and seek end and check a
>>> couple of bytes... that type of thing.
>> It seems to me that such a check would be incomplete and therefore
>> unreliable and that you may introduce this additional check in front of an
>> attempt to load a CDS files which is still never-the-less corrupt and so
>> still have to accommodate that potential.
>>
>> So instead of:
>>
>>    - attempt to load
>>      - abend if corrupt
>>
>> You would have:
>>
>>    - check validity (however you choose to do this)
>>    - if OK then
>>      - attempt to load
>>        - abend if corrupt
>>    - else
>>        - abend (due to detected corruption)
>>
>>
>> Notice how the flow simply and completely encapsulates the existing flow,
>> it
>> doesn't avoid or simplify any part of it.  It may simplify and streamline
>> the abend flow however - but if your application is required to deal with
>> failures efficiently because you expect more failure than success then you
>> should perhaps reconsider your approach entirely.
>>
>> :)
>>
>>
>> The overhead of "additional" loading is only necessary if you deliberately
>> perform a full load into some temporary object simply to ensure that you
>> will successfully be able to load it into the actual desired target
>> object.
>> But if you can simply load it into the target object then you don't need
>> to
>> duplicate the load attempt - just go ahead and try to load it and deal
>> with
>> any failure as required.
>>
>>
>> Introducing pre-load validity checks is a waste of time if an attempt to
>> load an invalid file causes nothing other than a "failed" load attempt
>> that
>> can be safely detected and handled.
>>
>> Pre-load validity checks would have value if the attempt to load an
>> invalid
>> file would cause some otherwise undetectable and undesirable side effect.
>>
>>
>> But it is hard to say for sure what is the correct/most appropriate
>> approach
>> without more detailed knowledge of the application and its operating
>> conditions.
>>
>> +0.02
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at delphi.org.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject: unsubscribe
>
>