dynamics ax : Push Customized form to All users - axapta

Recently, I was troubleshooting an issue related to user settings. There was a requirement to migrate the user settings from one environment to another.
There is an AX 2009 form which users make their own personalisations to, moving some of the fields around, or perhaps adding other fields (via the right click->setup functions) , so that unnecessary fields are hidden.
I have saved that form , so that it is available for me , but when i migrate the form to another environment i notice that the new user don't have any change on the form.
As we all know, User related setups for queries, forms, reports etc are stored in SysLastValue table. This is a system table and can't be accessed directly through AOT.

I think here is what you are trying to achieve:
http://axaptian.blogspot.md/2010/01/savecopy-filtersqueriesinquires-to.html
Basically, it allows to save custom filters and queries and pass it to other users. Although it copies only queries, I am sure it can be modified to copy any usage data.

Related

Drupal data entry forms & db structure?

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.

access forms as asp.net's listview

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.

In drupal, does features ignore or delete fields on live data?

We're considering using Features module for pushing out changes to production servers.
If a feature is to update an existing node with exisiting data, how will it behave?
For example, if the update will remove a field, will it remove all data corresponding to this field? If I just rename a field, will it create a new field on the node on the other server or will actually rename the field?
In general if you remove a CCK field on your local site -- you are liable to loose all your data in it. So if you move it to production, using features, the CCK field will get deleted on production and you will loose all your data there too.
Features repeats the same actions that you do on local machine on production machine. So if you simply rename the label on the field (or even the widget type on local machine) you are not going cause any data loss on local. That's because CCK allows people to change Labels and Widget types (though you cannot change the machine name anymore). Enabling the "renaming" feature on production will not cause data loss there too, just the label of the CCK type will change there.
You can perform the above as a simple experiment to verify it.
I am assuming you're not using crazy modules like http://drupal.org/project/cck_field_rename I don't know how features would behave in those scenarios.

Use ASP.NET Profile or not?

I need to store a few attributes of an authenticated user (I am using Membership API) and I need to make a choice between using Profiles or adding a new table with UserId as the PK. It appears that using Profiles is quick and needs less work upfront. However, I see the following downsides:
The profile values are squished into a single ntext column. At some point in the future, I will have SQL scripts that may update user's attributes. Querying a ntext column and trying to update a value sounds a little buggy to me.
If I choose to add a new user specific property and would like to assign a default for all the existing users, would it be possible?
My first impression has been that using profiles may cause maintainance headaches in the long run. Thoughts?
There was an article on MSDN (now on ASP.NET http://www.asp.net/downloads/sandbox/table-profile-provider-samples) that discusses how to make a Profile Table Provider. The idea is to store the Profile data in a table versus a row, making it easier to query with just SQL.
More onto that point, SQL Server 2005/2008 provides support for getting data via services and CLR code. You could conceivably access the Profile data via the API instead of the underlying tables directly.
As to point #2, you can set defaults to properties, and while this will not update other profiles immediately, the profile would be updated when next it is accessed.
Seems to me you have answered your own question. If your point 1 is likely to happen, then a SQL table is the only sensible option.
Check out this question...
ASP.NET built in user profile vs. old stile user class/tables
The first hint that the built-in profiles are badly designed is their use of delimited data in a relational database. There are a few cases that delimited data in a RDBMS makes sense, but this is definitely not one of them.
Unless you have a specific reason to use ASP.Net Profiles, I'd suggest you go with the separate tables instead.

Need an application design advice

I'm developing a web application which processes invoices(the functionality is not limited to invoices, but it doesn't matter). One of the parts of the workflow is to print invoice after it was published. This means that the website user is able to select 10-20(and more) invoices and print it at once. Also there may be several invoice templates which may be customizable(this is one of the key requirements).
I should also mention that we decide to generate PDFs from the html code and then print it. So as the PDF creation process may take some time to complete we decided to use a windows service for invoices printing.
So, summarizing we have the following requirements:
There should be customizable invoice
templates;
The website user should be
able to specify which template he
want to use with the invoice item
specified;
There should be a possibility to
print one or several selected
invoices in one click.
Our first idea was to use user controls as invoice templates. The user control will be responsible for invoice layout. This also means there will be a base class for these user controls through which we will be able to define a data source for the controls.
In this case we may even allow users to modify ascx file (or something similar) to edit basic captions if necessary.
The problem begins in the windows service where we are unable to generate output for user controls. So the other solution is to use http handler or web service to generate user controls output and transfer this to the windows service. But this complicates the solution (e.g. we need to use authentication for this and similar problems).
Maybe there is a much more simpler way to do it?
Thanks in advance.
In response to your comment, I suggest you have the website generate the HTML and save it into a 'GeneratedInvoice' field in your DB, which the service then processes (i.e. converts to PDF however your pdf conversion software does it). It's appropriate because you have a 'saved' copy of the generated invoice; i.e. if your invoice processing routine changes (different styles, etc) your old invoices aren't affected, and yet you can regenerate a given bunch in a possibly 'new' format if required.

Resources