-
Whatever fields you have bound to that datasource are going to be changed when you do the query. That's the nature of the beast. When you query, it returns a set of data. Any controls that bind to that datasource are going to be updated with that new set of data.
If you don't want that to happen, then you need to have a separate data ...
-
The select is failing, thus the .text property not valid.
Sounds like the issue is likely with the namespaces. Assuming the node names are all accurate, check to make sure each node has the appropraite namespace. For example, "my:" on dataFields looks suspicious to me.
-
Much of what you describe you should be able to do with web-enabled forms. Export to Excel -- I don't think you can directly do that with web-enabled InfoPath... but workflow (employee-to-manager) and I think even the email should be possible.
However, if web-based is the most important criteria, then you might want to consider your other ...
-
Every platform has its challenges and limitations. Your choice depends on a lot of factors such as cost, accessibility, maintainability, etc.
InfoPath makes developing forms much faster and easier than ASP.NET, however, each computer that runs the form must have a copy of InfoPath installed.
As for limitations, it all depends on what you want to ...
-
You might find that trying to do all this with expressions and XPath is more complicated than its worth. Move to code for something like this and it will be more straight forward and probably more performant.
-
Not with these methods. You would need a web service. Qdabra.com produces one you can try out before purchase.
However, typically in most companies, the network username IS the email. So for company XYZ, the email would be username@xyz.com
-
Multiple row repeating tables are not directly supported in InfoPath. However, there are some alternatives:
1. Create a single column repeating table, and then inside that column, add a layout table with the construction you desire.
2. Use a repeating section instead of table, and then again, use a layout table inside with the design you like.
-
1. You can create a form which has its main data source bound to the database tables. Then submit is straight forward.
2. You can write a Web service which submits the data to the database... will likely require some form code as well.
-
It sounds like you don't even need cascading lists. If what I understand so far is correct, the user selects the person from the list, and then all you want to do is populate a few fields with values associated with that person--that there will never be more than one value per field associated with that person.
If this is the case then ...
-
You have two options:
1. Move all the code to rules. This might be possible if you are not doing anything fancy and just filling in the query fields.
2. Move all the rules to code. This is probably easier and safer for a couple of reasons:
a) Sounds like all you have is the query. This can be done in code by calling the Query() ...