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.
Related
I am new to Google App maker and I don't have a lot of experience with coding either (sorry :/). Since App maker is marked as low-coding app builder tool, I assumed it was not that hard to make a very simple app with it. However, for me it is.
I need to make a simple app for demonstrations purposes only (so Cloud SQL and other complex database solutions are not in my interest here). I want to make it using calculated models (correct me if I am wrong, calculated models are just temporary solutions, since apps need to have like real databases to be fully functional?).
My app is basically made of 2 datas: 1) Employees and 2) Departments
-> Fields for "Employees" are: First name, Last name and Department.
-> Field for "Departments" is just Department name.
My app is supposed to look like this:
1st page: Table with current employees that has a button to add new employee,
2st page: Table with all department names (e.g. marketing, finance...) that has a button to add new department name,
3rd page: Form that opens when I click on add new employee button in which I can insert their first name, last name and from drop down menu choose department,
4th page: Form that opens when I click on add new department button in which I can insert new department name.
5th page: Form (or some other widget, not sure here) that has option to insert first and last name in order to find out what department that employee is assigned to.
I tried to make first 4 pages, but I end up with forms that I cannot insert anything into them. 5th page is still too much for me.
I hope you understand my struggles and if you know how to do it please share your knowledge. Thank you very much!
Calculated models are kind of like SQL views - they are not necessarily for temporary solutions. Every time you load a calculated model the script you write under that model's datasource is ran. That script usually loads data from an external source (I.e. grabbing stock prices from an API, loading data from an external SQL server, or generating random placeholder data).
You could use the cloud SQL models for this application that you are building - your table with all department names that is supposed to be displayed in the second page could just be a cloud SQL table with one single field for a department name.
I suggest you work through the example apps so you can get a better understanding of how the different components work. Here is a link to one for you to get started.
In short, you're going to create a few models to store information (I suggest using cloud SQL as the calculated models will require code whereas cloud SQL is more plug and play through app maker's bindings). Before you create any pages try to lay out how your databases will look as that will dictate how you set bindings or program your scripts.
Asking to completely make what is essentially a combination of the tutorials already provided by Google is pretty counter intuitive - you should ask more specific questions in regards to implementation.
As for App Maker being a low-code environment, that's only partially true. For very, very simple apps (think glorified forms) you will need only a couple lines of code and can probably do everything through drag-and-drop. However, anything more complicated than a simple form will almost certainly require a good chunk of actual code. There are plenty of resources online to learn Javascript.
You might want to try a google partner like AppSynergy for building stuff like this. It might be overkil for what you need (or maybe not if you intend to build a lot more stuff).
I have a problem I'm trying to solve and I'm really not sure I'm, A) solving it the correct way, and B) able to do what I want.
I have a List Page that is a basically a summary table (transportation table) that has a record in it for every Sales, Purchase, and Transfer order that we will ship. With it is a pile of rolled up information and such that's common from the 3 sources. We use this table on a few list pages and link out to where we need to. This was all built by someone else, but I'm maintaining some parts around it.
I've gotten a request to have the preview pane on a summary table based list page show the lines from the source order. So, if a "sales order" is selected in the grid, show the lines in the preview pane for the "sales order" that was selected. Same for a purchase order and transfer order.
So, my idea, based on pure ignorance and not a ton of experience with Dynamics is that I would just swap out the preview pane based on the source order. The SalesTableListPagePreviewPane for instance has already been updated to work with linking to this summary table. So, I wanted to just change the part reference at runtime.
I've managed to get the FormRun on a list page interaction class from the datasource. I've managed to get a list of the parts via the PartList object. But, I have no idea how to continue on to actually swap out a part reference.
Am I heading down the correct path? Is this a completely wrong Dynamics AX pattern?
Your assumption, that you can dynamically (run-time) change the parts of the form, is wrong.
Listpages especially are quite static, the only code available through interaction classes. It has the benefit that a listpage can be easily deployed on Sharepoint Enterprise Portal.
You have several options:
Use 3 different listpages for each type of transport
Use a common relation table with 3 sub-tables (sales, purchase and transfer)
The last option will enable you to do an outer join on the 3 sub-tables.
The common relation table could be a union view, but I doubt it will perform well.
I'm trying to build a Drupal site in which users can input records containing data about "customers", "employees" and "sales".
I would like to be able to create a form(s) which takes data about a sale/customer/employee and can be associated with a record of a customer/employee(who made the sale)/sale.
I would also like to be able to display records showing a list of sales or customers or employees in which when clicking one record, it will open a page displaying all the relational data.
I'm new to development and am searching around like a headless chicken lol. I was thinking of using content types for sales/employees/customers and using individual nodes for each record then using something like views to displays filtered lists, but I am unsure if this is the best way to go about/structure it (maybe I should use separate custom tables or database and use a custom module to fetch the data?). It would also be nice if some of the fields can populate other fields based on it input and also if some fields can utilize a sort of auto-complete by garbing data from other records, or is that asking way too much?
Thank you for any suggestions you might be able to give me.
I, for one, would certainly prefer using a custom separate database and leave drupal databases to its own devices, if you would ever need to upgrade the site to a higher version of drupal it helps if you don't modify it, and also consider using webform (http://drupal.org/project/webform) as it makes development easier both in components and hooks.
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.
This is a purely theoretical question (at least until I start trying to implement it) but here goes.
I wrote a web form a long time ago which has a configurable section for getting information. Basically for some customers there are no fields, for other customers there are up to 20 fields. I got it working by dynamically creating the fields at just the right time in the page lifecycle and going through a lot of headaches.
2 years later, I need to make some pretty big updates to this web form and there are some nifty new technologies. I've worked with ASP.NET Dynamic Data just a bit and, well, I half-crazed plan just occurred to me:
The Ticket object has a one-to-many relationship to ExtendedField, we'll call that relationship Fields for brevity.
Using that, the idea would be to create a FieldTemplate that dynamically generated the list of fields and displayed it.
The big questions here would probably be:
1) Can a single field template resolve to multiple web controls without breaking things?
2) Can dynamic data handle updating/inserting multiple rows in such a fashion?
3) There was a third question I had a few minutes ago, but coworkers interrupted me and I forgot. So now the third question is: what is the third question?
So basically, does this sound like it could work or am I missing a better/more obvious solution?
Did you try creating a FieldTemplate that had a "ListView" of all the Fields? (the ListView would use Dynamic Data to determine which FieldTemplate to display for each field.)
I don't see why this would not be possible. Although, "out of the box", you may have to hit "edit" on each row of the new FieldTemplate's ListView to edit the values. It would be like replacing the "Order Details" link in the Orders List, with an inline List of the "Order Details".
1.) Not very nicely. Can you imagine showing a DateTime, Integers, Phone numbers, Urls, etc with just ONE user control, like text.ascx? Why not have multiple field templates and use UIHint to specify usage per column?
2.) Yes.
3.) Define basically?
regarding one to many relationships, you might have a look at the ListDetails.aspx Page Template in Dynamic Data. Hope this helps.