General

Re: Repeating section or master/detail woes

Greg Collins — Thu, 11 Nov 2004 18:37:02 GMT

You are right -- I don't know much at all about datasets at this point. Perhaps I'll eventually work on a project that will force me to learn them.

I'm glad you were able to figure the issue out, and thank you for sharing your findings with us.

As for the other repeating issue, perhaps you can modify the manifest or view .xsl file to fix that? Design two new blank forms, add in a repeating table, make one form so that the insert shows and the other so that it doesn't and then compare the files from each to see what the difference is to find out if you can fix the issue yourself.

Greg Collins [InfoPath MVP]

Re: Repeating section or master/detail woes

jonbrave — Mon, 08 Nov 2004 12:47:45 GMT

Greg,

First off, I think congratulations are in order, according to the other poster! :) So congrats to you (you must be mad...)

Thanks for pointing me in the non-master/detail direction, at least that's a start!

I (think I...) have solved my own problem, at least a bit, and posted to MS communities IP to that effect. A lot of my probs are to do with using datasets, I think, and, no offence to you, I think that's an area you're not so familiar with.

If you were designing your schema for this you'd have TableB *nested as a child* of TableA, right? It turns out (according to me) that, when the schema is being generated from a dataset, by default you don't get this, even if you have a dataset "relationship" defining the parent-child. You have to go set a "Nested=true" Property on those relationships in your dataset which you want IP to create as parent/child. This causes the XML to come out nested, whereas by default a dataset gets all its tables exported "flat".

Now that I have done that, I get the proper "nesting" in the IP hierarchy. And the "control type mismatch"/red asterisk has gone away. It seems to me understanding this is absolutely vital to anyone using datasets, but it's not at all clearly documented. You may want to know this if anyone ever asks about "datasets not having their tables nested".

I'll probably have to post separately about the repeated section/single section issue. I'm claiming you have a dataset issue there. For example, according to me, if my top-level is a table from a dataset, I *have to* have that as a repeating section *and* I can *not* tell IP that I don't want "Insert Item" buttons (I don't want users to be able to create extra rows) --- it's all greyed out. I tried posting is MS communities and one of your guys (Brian Teutsch) said he didn't know but didn't think it should ever be like that... :(

Re: Repeating section or master/detail woes

Greg Collins — Fri, 05 Nov 2004 18:23:33 GMT

I'm not suer how much I'll be able to help on this one, but let's try:

First of all a master/detail control is probably not the choice for you. Reason? Because it expects there to only be 1 table on the back end, not 2.

What it really sounds like you need is some way to select an order, have one section show the details of the selected order, and have another section that has a repeating list of the items for that order.

Both sections would be filtered on the selection of the specific order (whether that selection is a drop-down list box, or what).

I hope some of that helps.

Greg Collins [InfoPath MVP]

Re: Repeating section or master/detail woes

BrownR — Thu, 04 Nov 2004 13:55:21 GMT

Gregs very busy, I'd give him alot of time to respond. Also with a new child it makes it that much harder. :-)

Re: Repeating section or master/detail woes

jonbrave — Thu, 04 Nov 2004 08:12:26 GMT

Bump (Greg?) :)

Repeating section or master/detail woes

jonbrave — Tue, 02 Nov 2004 17:12:52 GMT

Hope you're here, Gregg, you wonderfully helpful person! :)

I can't get either to work, and don't know what I'm supposed to do. here, hopefully, is a simplified explanation of what I'm trying to achieve, which ought to be "common":

* Web Service returning single dataset containing multiple tables
* TableA is the master (e.g. "Orders")
* TableB is multi-to-one detail (e.g. "OrderItems")
* Suitable key field linking the two (but note, no "relationship" in schema, for complex reasons --- don't know whether that is of any relevance).

Let's say, I want a form to allow adding/updating of Order, together with its OrderDetails. Two approaches seem possible:

1. [Currently adopted] I'll manage with assuming dataset will only return *1* row in TableA (for updating) [and all rows in TableB will be children of row in TableA]. Can't convince IP of this (it decides data table could have many rows), so have to define it as *repeating* section. OK. Then try to add TableB (also repeating section, this time required). If I place control *inside* TableA repeating section, IP complains about "control type mismatch" with red asterisk, whatever I do; although all seems to work, can't save form since error. If I drag TableB below TableA's repeating section that clears the error. But then nesting is wrong, and "Insert Item" will place multi Orders before all OrderDetails.

2. [Attempted] OK, perhaps this is a master/detail situation. I try TableA as master, with suitable deleting and recreating to make TableB detail via key field link. But then TableA *must* be represented by "Repeating Table" control, which is all wrong.

I'm trying (obviously) to achieve layout like:
Master
Field 1 Field 2
Field 3 Field 4
...
Children Detail
Line 1
Line 2
....

From one parent record, I may have several different "detail" tables, (each) with multi-rows (at present one, but there are further detail tables to include).

I might have a "search for record by key" control to pick master row to be updated, rather than a master *table* control. That causes row + child detail rows to be read, ready for update; then separate "Add New" button for adding new master row (clears out info there), together with whatever child detail rows required.

I hope all this makes sense. It seems to me a common situation.

Which approach *should* I be taking? Nested repeateds or master/detail? And why do neither of them seem to be right...? :)