Should I use objects or XML
-
Hi, Right let me briefly explain what I am trying to achieve and perhaps someone might be able to point me to the best method to achieve it. I am creating an updater that will run update sql on clients systems, by using sql embedded into an XML file. This updater needs to be version independent of our client platfroms. The updater is just updating a library that the system references. My problem is that if I apply an update that uses a newer database schema against an older version, it will cause the update to fail. How would we go about creating objects that perhaps are dynamically built according to the schema of the database and being able to ignore any new columns that have been added. What I want to achieve is an updater that will update a library in the database, regardless of what version of the system it is using and if that a new update is being applied to an old version it will be able to handle itself and apply only the data that is needed according to the schema. Sorry this is a little hard to explain, hopefully that makes some sense. We have looked at an object approach or perhaps doing it all via XML and are not sure which is the best or if we choose object method how do we go about it. Regards Paul
-
Hi, Right let me briefly explain what I am trying to achieve and perhaps someone might be able to point me to the best method to achieve it. I am creating an updater that will run update sql on clients systems, by using sql embedded into an XML file. This updater needs to be version independent of our client platfroms. The updater is just updating a library that the system references. My problem is that if I apply an update that uses a newer database schema against an older version, it will cause the update to fail. How would we go about creating objects that perhaps are dynamically built according to the schema of the database and being able to ignore any new columns that have been added. What I want to achieve is an updater that will update a library in the database, regardless of what version of the system it is using and if that a new update is being applied to an old version it will be able to handle itself and apply only the data that is needed according to the schema. Sorry this is a little hard to explain, hopefully that makes some sense. We have looked at an object approach or perhaps doing it all via XML and are not sure which is the best or if we choose object method how do we go about it. Regards Paul
Hmmmm, Interesting issue. I know we have had similiar issues in the past = Can I ask how the clients get the update file in the first place ? Is it from some Web Service or do they just download it etc? I'm also presuming that the Actual application itself which opens this XML file will know that it is possible that it will run SQL on potentially multiple different databases (i.e. ones with different schemas and potentially different versions). If that is the case then why not actaully send down a ZIP file or Cabinet file with several XML files. One primary XML file with essentially a manifest set of nodes - each one referencing one of the other XML files in the zip/cab, seperated by Version/Schema. For example the primary XML file might look something like this... It would then be up to the app itself to work out which version of client database and which schema (or whatever criteria you need) and then check this against the manifest XML file and then load in the relevant SQL xml file and then run the SQL contained within it. Whilst it may seem inefficient to ship all the files to every client, once it's zipped or compiled into a cabinet file the actual file will be pretty small and you also enjoy the benefit of keeping the update logic seperate for each schema/database type. Mark
-
Hmmmm, Interesting issue. I know we have had similiar issues in the past = Can I ask how the clients get the update file in the first place ? Is it from some Web Service or do they just download it etc? I'm also presuming that the Actual application itself which opens this XML file will know that it is possible that it will run SQL on potentially multiple different databases (i.e. ones with different schemas and potentially different versions). If that is the case then why not actaully send down a ZIP file or Cabinet file with several XML files. One primary XML file with essentially a manifest set of nodes - each one referencing one of the other XML files in the zip/cab, seperated by Version/Schema. For example the primary XML file might look something like this... It would then be up to the app itself to work out which version of client database and which schema (or whatever criteria you need) and then check this against the manifest XML file and then load in the relevant SQL xml file and then run the SQL contained within it. Whilst it may seem inefficient to ship all the files to every client, once it's zipped or compiled into a cabinet file the actual file will be pretty small and you also enjoy the benefit of keeping the update logic seperate for each schema/database type. Mark
Hi Mark, many thanks for response in regards to my question. The way the system will work is that we send an update to the client, they are than able to upload this xml file using the application, the application then applies the updates contaied within the file. We really want to be able to move away from shipping files with multiple versions, as we want the updater to be completly version independent. The reason we have chosen XML initially is that we can compare old xml to new xml file to genreate the necessary insert, updates and deletes. Plus if there are new columns it just means tewaking the sql that outputs the xml. Where as to do it by an object model, any methods/fucntions have to be all updated to cope with new columns/tables and any calls to those methods/functions must be updated. This would be laborious, unless there was a method to do it dynamically. The reason we are looking at an object model is that all our programming in the system uses this and we would like to replicate that for ease of use, but I do understand that XML is the most appropriate method. Thanks again Paul