Hi
I am using the VS xsd designer to create a strongly typed dataset. The dataset is apparently successfully created, with no warnings or errors given. Is it not then to be expected that this dataset then should reflect all the details put into the xsd? Somewhere down the line there is not a 1:1 relationship. Be it that .NET is so tightly coupled to xsd, xml and dataset I would have expected any discrepancies to have been well documented and warnings errors / grayed out option boxes to be implemented. I have seen bug reports related to this, but these should not be bugs. Responsible developer or tester should have discovered these well ahead of time of release. However hard to program, still so elementary faults
I just don't know when to trust these most central building blocks any more!
I am developing an involved application regarding tables and relations, expressions and limiting the user to enter values in correct formats. It is not involved in that I only need a single xsd defined dataset, a single datagrid at first, and a load/save of dataset to an xml file. Had the dataset enforced the facet restrictions in xsd, allowed expressions to refer to parent row and not failed upon parent row(id) changing. Had the datagrid always updated upon changes to a row of the dataset. And had the datagrid supported comboboxes (based on relations) in addition to todays text and check boxes. And had the datagrid had some minor standard autoformatting options. Yes then a working structure could be implemented without any programming worth mentioning. A single datagrid could be used to edit the whole of the dataset structure which could be saved and loaded to file as needed, bad gui but a fully working application. Energy could then be used to implement alternative and better looking gui
As is I have no idea as to when to trust the datagrid to update epressions based on dataset changes made through some other datagrid or other gui. It seems a bit random. Documentation is of little use, and having 60 odd tables I cant assume things to work.
As is the promised facet restrictions does not work. Have even found (a good quality!) text book with ready example showing how to use facets to restrict number entering. Sample code fails, as does VS's own xml data editor (editing an xml file based on an xsd file created using VS own xsd editor). How can sw developers and testers not see this before release? Documentation of course just short of implementing these faults in their sample code
The parent expression works in todays newest release of VS. Changing the parent row id does not create errors; at least it seems to work ok. But how could this fault not be seen earlier before release? This is the most elementary thing during testing of relational structures. However having the usual complex relational structure it may be hard to see this elementary error to be the cause of problems. It may also be seldom triggered and difficult to discover during app testing, simply because your app may seldom allow for changing of the parent row (id)
There is a lot of documentation covering a lot of code in VS. Following the reality of object oriented programming. There is always a snippet of code object that can do the job for you. Its just that one often ends up spending more time looking for that snippet of code than one would need to program it. There are waste snippets of documentation, but they always refer to some other snippets of documentation. Less is better if you ask me. Give me a solid overview, and tell me there what does and does not work. Dont tell half the story of what does work through zillions of small doc snippets
Frustrated, huh..
How to know what actually does work with xsd/dataset/ (datagrid)? What part of xsd is 1:1 with dataset
Rgds
