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@delphi.org.nz > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: > unsubscribe > _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
