Simply - we have a custom application record that is loaded via File Parser, we want to be able to update one field for certain rows in that table as a part of a business process.
I added that table to to the underlying Population Update records but it will not not let me run the process from PIA. The Population Selection dropdowns are disabled on the run control page.
I am not certain if I should go through with this solution, or find some other way to update that record accordingly (custom app engine, etc...)
Any help would be appreciated.
Related
In my current assignment - I have to implement a solution for the session state management issue. The current implementation is as follows:
There is a asp.net form that allows you to add multiple entries to form a batch.
The fields represent a single entry (most of the fields are auto complete) - once you fill all the fields and click the 'add' button - the entry gets added to a grid view - Each time the 'Add' button is clicked it causes a post back and the grid view repopulates displaying the previous entries.
After repeating the above steps multiple times to enter multiple entries - all are displayed in the grid view - you then click the 'Enter Batch' button - that submits all the entries in the grid view as a batch to the database.
The issue: To enable most of the above functionality - there is session state (InProc) implemented all over the page and other pages as well. The problem is - Users can open multiple instances of the same application, and then the application goes crazy. The other issue being - at times the application kick off the users and they have to re log in and when the do that all the entries they where doing in the batch are gone from the gird view.
I see session implemented everywhere on the web form. The most obvious solution to resolve the above two issues - is to implement a Session State (SQL Server) mode.
But before I move ahead with the implementation I have couple of questions, If anybody can help:
1 Can I change the current implementation (so that I don't have to re write the session variables already used on the web form - as they are two many) - I tried to change the web.config to have the (sessionstate cookieless="true" - I was hoping this would put the session ids in the URL, in turn enabling session state of multiple instances) - however after doing that - the auto complete feature on most of the fields don't work, so I have change the config to allow cookies based. So is there a way to change the current session implementation to make it work properly around multiple instance of the application.
If I have to implement session state afresh - can someone give me a brief overview of how to implement the Session State (SQL server mode) so that it works around multiple instances - like what to use for unique key (how to set and get session variables base on this key for multiple instances) and how to configure the tables in database etc.
Note: the current session state is 'InProc' mode and I can say that cause there it is not set anywhere so I think that's the default. The session variables are pretty standard in the current implementation.
This is a new project I have started - and this is my first assignment - however the code is really messed up - it dose not have a modular or even the basic 3 tier implementation. The code is very unmanageable and hard to debug.
Any help and suggestions are much appreciated. Thank you guys.
All that is required is given at Session-State Modes.
Your code for storing/retrieving session state does not change.
Is State Server Mode out of the question?
I am currently undertaking an exercise to research on a number of JS MV* frameworks and select one that best suits the team's needs. Knockout is one of the contenders that I am learning about.
One of the most important requirements is for changes in the data in a view model to be broadcast to all the views that use such data. For example, lets say we have client details listed in a data grid on a page, clicking on any row in the data grid brings up a pop-up dialog where the user can edit the values of the selected row. When the change is made and the user clicks 'Save', the data is updated in the database. But what we also want is that the change be reflected in the local ko.observablearray and then for any other views that use this 'clients' collection to refresh themselves with the new data. In other words the views must refresh themselves with the data in ko.observablearray rather than get a fresh list from the database.
I have been successful in doing this - have one a single .cshtml file which houses the data grid and a form to create new row in the data grid. In this scenario, the data in the grid refreshes correctly. But when the change happens on a another cshtml file, I am not able to carry these changes across to the other views. Can this be done in knockout and if yes, please point me to an example of how and where this has been done.
I would use a Event aggregator pattern. I have made one for SignalR
https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy
Install usign nuget
Install-Package SignalR.EventAggregatorProxy
If you have no use for SignalR you can then extract the relevant parts from my lib, demo here
http://jsfiddle.net/jh8JV/
Hopefully someone can help me with my problem.
Background
I have create an InfoPath form that is to assess project risk. It allow the user to select a scenario and in return the form returns a risk class and set of actions. The actions are displayed on the form as a multi selection list box, because I was unable to display the action list in a text box.
The form is going to be used in multiple locations, thus will be published to multiple sharePoint sites across Australia and so for easy of updating all of the scenarios and actions will be loaded from a universal SharePoint list. This will then not require the republishing of the form with every update.
The Problem
If a new version of the form is rolled out. E.g. any of the scenarios or actions change. I can not have any previously submitted forms change with it, as the previously submitted answers in the form may not be relevant in the old versions.
This is not an issue with the Scenario fields as they can be tagged to load only once. But the multi selection list box works differently and loads its data every time the form is opened.
The Question
Is there anyway of loading the data in the multi selection list box only once?
If not is there anyway I can load data into a bulleted list or some other field that I can load only once on open of the form for the first time?
Hopefully someone can help.
I had the same issue - I don't want data in old, previously submitted forms to refresh their data for dropdown, tables, etc when they are opened in the future. They need to always use the same data they were submitted with, regardless of weather the database values have changed or not.
To do this, I first unchecked the option "Automatically populate data when the form is opened". Then I unchecked the option to tell data to expire after X amount of days - so i always know the form will have data cached.
I then created a field to serve as a marker for weather to update values from the database or not. Then I used custom code to refresh secondary datasources from the database if needed. In my form loading event, I check to see if the from has already been submitted or not using my marker field.... if not previously submitted - refresh the data - if previously submitted- do not refresh data.
On submition of the form, i set my market field to indicate the form is locked and should never update its secondary sources
Hope you get my idea.
Cheers
If a new version of the form is rolled out. E.g. any of the scenarios
or actions change. I can not have any previously submitted forms
change with it, as the previously submitted answers in the form may
not be relevant in the old versions
I do not understand your problem since the previously created XML data forms are opened with XSN templates with which they have been created (i.e. previously created XML data forms are opened wh the use of old XSN template forms). If it is not so, then open a question why it is failing for you.
Also, I do not understand why do you need to load choices from external source, if it should be fixed once and forever, load it from resource XML file embedded into template itself or choices entered manually (Enter choices manually in properties of Multi Selection List Box). So, they will be stored in the used template
Please check
Free Training: Data-Driven Design - Using Default Data (Lab 1)
on step-by-step tutorial on better ways how to create in Infopath a Quiz form with Default Data (questions and answers in modules)
I am in the process of migrating an Access application to Sharepoint 2010 (Enterprise). I would like to use as much Sharepoint "out of the box" funcationality as possible, but I am not opposed to creating some Web Parts.
I am struggling with the design of the "master" table in this application. The application is used to track employee productivity. Daily, about 50 users access the application and basically enter how many "Widgets" they completed that day. There are about 30 types of these "Widgets" and they don't change very often.
The table is designed with individual columns for each of these Widgets. This makes creating the Reports very easy, since all you have to do is select all the fields from the table and dump the result set.
The downside to this approach is obvikously the fact that the schema is "hard coded" (static). I have been asked (in the sake of time) to just normalize the table as much as possible (with CustomerIDs, EmployeeIDs, etc), but keep all the "Widget" fields in there.
I had proposed that we create a Master Detail type relationship where the users would Add a Row (perhaps in a GridView), select the "Widgets" they created that day (from a drop down) and enter their quantity. They generally only make 1 - 3 types of Widgets per day.
The users hate this design and want me to give them a data entry form with ALL the widgets displayed so they can just click in the box (beside the Widget they created that day) and enter their qty and then click save.
I know I could still create this type of Data Entry Form with a Master-Detail type of relationship, but I am pretty sure I couldn't using the SP Out of The Box forms. I would probably have to create a Web Part with a GridView and just populate the GridView with all the possible Wisdgets, then let the user enter the proper Qty(s) beside each widget they are made that day. Once the form is submitted back, I would then have to go through it and find any Qtys that are valid Numbers and add a (child) detail record for that Master record. (The Master Record would contain date, employee, customer, etc. etc.) The "edit" form would also have to work in a similar way.
This is a pretty "ugly" solution and I was looking for an alternative.
If I can't come up with a good alternative (and convice my manager that the code won't be too difficult to maintain or add too much development time to the project to complete it on time) then I will have to bring over this ugly, existing schema with all its wasted space and have "hard coded" stuff thoughout the application. (For instance, if I provide them with a SharePoint View to see how many Widgets of a certain Type were created, I will have to "hard code" all those values in the Drop Down and "Sum" the correct/matching database column. YUK.
Another consideration is the reporting. Right now all the reports just contain a column on the report for every widget. To preserve the look of these reports (if I use a Master/Detail relationship) will require "fancier" queries (Stored Procedures) to buld the proper result set in a "columuar" format. (And I am not sure how I would tackle laying out the SharePoint Views of the data in a similar fashion.)
It certainly would be "easier" to just leave the schema as is (and have all that wasted space in the table). I just hate developing an application that anytime we need to add a new "Widget" to the application, we have to change the application in several places and rebuild. (Although, my manager isn't concerned about that, he just wants to push it out, ASAP...sigh...)
Any help/recommendations on how to do this type of application (specifically how to create the data entry forms and views) in SharePoint would be greatly appreciated!
Shayne
Have you looked at these ideas:
http://paulgalvinsoldblog.wordpress.com/2007/12/24/implementing-master-detail-relationships-using-custom-lists/
http://blogs.msdn.com/b/alexma/archive/2006/04/10/610934.aspx
In my opinion you should be storing the data in list rather than SQL server. If you decide to use SQL server, look at BCS to build Master child view.
I made an access vba application where all my architecting was simply creating a one-to-many relationship between a "status" table and a "data" table that contained all the other details of my record. Created a form with the single click of a button with my "status" table open, and wallah,,, I got a form for my open or closed records that had dropdowns for each field where theres a related table. For activity tracking, I had to make a many-to-many table , and made a one-to-many for the status of those activities and again, clicked the create form and I was in business. To finish things off all I did was integrate a checkbox in my data fields and put buttons on my status forms that act on the record that got checked, and I was done, fast & painlessly, kinda.
Is there any ASP.net code generation of a data control in where I can just structure my MYSQL database, make the relationship and generate code of the RELATED "status" table and get my form w its related subform with text fields & DDL's automatically generated, fast? If not, what would you consider is the next best approach (i.e. using excel for replicating repetitive code)?
Take a look at http://www.asp.net/dynamicdata
As far as I know (having not used it myself) it will do what you need, ie quickly generating data entry pages from an existing sql schema.
Access can actually create .net forms when you use access 2010. (the forms are real xaml or so called zammel forms). The beauty of this system is you get to keep the same point and click approach that allows you to build master forms with child sub-forms. You not have to write one line of code and you not ever see one connection string. Only downside of this great new system called "Access Web Services" is it requires SharePoint (enterprise).
So, this is a true access development for the web, but you continue to use the Access client to build those forms. Those forms scale out to many users since you using xaml forms and SharePoint. Here is a video of this in action:
http://www.youtube.com/watch?v=AU4mH0jPntI
At the half way in above, note how I switch to running the access application 100% in the browser.