Gustav Brock
Gustav at cactus.dk
Wed Nov 9 05:34:03 CST 2011
Hi David I would say that using XML is mostly for fun or if you need to exchange the data directly with "something else" that requires XML. Or if you somehow need manually to view or edit the data independently of your app, as this can be done with an XML tool like the simple and free XML Notepad from Microsoft. Only one file is used, thus all tables will be held in this, but records of these will be separated to fit the hierarchical structure your relations define. Thus, for example, records of order lines will be split to be stored with the orders they belong to, and the orders will again be split to fit the customers these belong to. You can then figure out that any saving of a record forces a rewrite of the full file. This, however, is very fast for small files. My recommendation would be to use the SQL Server Compact Edition. Only a small executable runs it, and SQL syntax is identical to its bigger brothers. Not that you need to write SQL - actually you should avoid it by using higher level coding like DataTables or EF (Entity Framework). Don't forget to sign up with our dba-VB list. /gustav >>> newsgrps at dalyn.co.nz 08-11-2011 20:31 >>> Thanks John, Would 50 fields (mixture of text and numbers) and 200 records be considered small? Not having dealt with XML before, would the idea be to load the table at the beginning of a session and then save it at the end (or at regular intervals)? David At 9/11/2011, jwcolby wrote: >For small tables using XML to the local directory would be just fine. > >John W. Colby >Colby Consulting > >Reality is what refuses to go away >when you do not believe in it > >On 11/8/2011 2:04 PM, newsgrps wrote: >>This is sort of off topic but I will give it a shot. >> >>I am considering learning dot net and thought I would do a simple >>windows application project that >>can be distributed that has a single table of address information >>(perhaps being expanded to up to 5 >>tables). >> >>My reading indicates that I can create an installable package ok >>but I am unsure about the database >>part. I have seen examples which use SQL Server or Access but both >>of these seem overkill in this >>situation - likely users will not have either of these installed >>and it seems crazy to include >>runtime installations just for one table (or even if there were up >>to 5 tables). >> >>Assuming that a similar application was created for actual >>distribution what would be a suitable >>solution for storing the data in these circumstances (or is a dot >>net application not the right tool >>for this job?) >> >> >>Regards >> >>David Emerson >>Dalyn Software Ltd >>Wellington, New Zealand