I need my conversion table (we integrate data from other system where their values mean another thing in our AX instance) to be encompassing all companies.
When I deploy the project, I'll upload that table's data through an Excel import but I don't want to do it for all 5 of our companies.
I know when code runs as Admin, it fetches data from tables regardless of company (unless you specify so in the where clause) but I want standard users to see the table's data regardless of the company they are in when they run the code.
Is this possible ?
Thanks.
Yes, there s a property on tables called SaveDataPerCompany. The default is yes but if you change it to no, then essentially the DataAreaId field is no longer applicable and the same data will be seen in all companies. You change the property by finding the table in the AOT (e.g Data Dictionary > Tables) and right-clicking it and choosing Properties towards the bottom.
Related
I am working on an asset tracking system that also manages the concept of "projects". The users of this application perform maintenance activities on their customer's assets, so they need an action log where actions on an asset start life as a task in a project. For example, "Fix broken frame" might be a task where an action would have something like "Used parts a, b, and c to fix the frame" with a completed time and the employee who performed the action.
The conceptual data model for the application starts with a Customer that has multiple locations and each location has multiple assets. Each asset should have an associated action log so it is easy to view previous actions applied to that asset.
To me, that should all go in one table based upon the logical ownership of that data. Customer owns Locations which own Assets which own Actions.
I believe I should have a second table for projects as this data is tangential to the Customer/Location/Asset data. However, because I read so much about how it should all be one table, I'm not sure if this delineation only exists because I've modeled the data incorrectly because I can't get over the 3NF modeling that I've used for my entire career.
Single table design doesn't forbid you to create multiple tables. Instead in encourages to use only a single table per micro-services (meaning, store correlated data, which you want to access together, in the same table).
Let's look at some anecdotes from experts:
Rick Houlihan tweeted over a year ago
Using a table per entity in DynamoDB is like deploying a new server for each table in RDBMS. Nobody does that. As soon as you segregate items across tables you can no longer group them on a GSI. Instead you must query each table to get related items. This is slow and expensive.
Alex DeBrie responded to a tweet last August
Think of it as one table per service, not across your whole architecture. Each service should own its own table, just like with other databases. The key around single table is more about not requiring a table per entity like in an RDBMS.
Based on this, you should answer to yourself ...
How related is the data?
If you'd build using a relational database, would you store it in separate databases?
Are those actually 2 separate micro services, or is it part of the same micro service?
...
Based on the answers to those (and similar) questions you can argue to either keep it in one table, or to split it across 2 tables.
I have seen several members on this forum warn about creating tables in a database while the app is running. Instead it is encouraged to create the tables while programming, and only fill the tables with data during runtime.
E.g while creating a note-app it would be convenient to let the user specify a name for a single note, and let this note be created as a table in a database. This by creating the table at the time the user creates the note, and letting the name of the note be the name of the table. Why would this be a bad practise? Have I misunderstood?
It would be highly inconvenient for both you and the user of such an app to create a table for every note the user might want to add. It's just not the way it works. A table should contain rows of information of the same type, such as a note for example, and each note should be added as a row/record in the said table. The table should be called notes for example, and if you want a name for each note, it can be a column in the notes table called name.
An analogy would be, if you are taking notes manually (without an electronic device that is), would you have one notebook with you and just add notes on different pages as you need to, or would you carry around a bag full of notebooks so that whenever you want to add a new note, you would add each note in a separate notebook?
The notebooks being equivalent to database tables in this analogy, and the pages of the said notebook being equivalent to rows in a database table.
I can't think of a reason for creating tables during runtime really. The database structure should be "set in stone" so to speak, and during runtime you should only manipulate the data in the database, which is adding, deleting, or updating rows/records in already existing tables. Creating tables during runtime is a big no-no.
I probably don't understand your question correctly, but it seems to me, that what you really want to do is to create a new row in a table I the database?
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 am thinking about ways to manage a table naming issue for an application I'm planning.
Currently there is a table that contains raw materials (approximately 150 rows) and each row has about 20 columns mainly float-value numbers used for calculations. For reference, let's refer to this table as 'materials'.
As these number columns are periodically updated and some users may also wish to create custom versions, I will create a management utility that allows copy/edit of this material table but, crucially it will only allow "save as" under a new table name so that data is never destroyed.
Thus using an automated routine, I'll create 'materials_1", "materials_2" and so on. When a calculation is done in another part of the website, I will store the name of the materials table that was used for the calculation so in future there can be audits done to find where a result has come from.
Now... is it possible for me to do this in an entity framework / unit of work/ repository way (like John Papa's codecamper example) without me having to continually edit the datacontext and add the newly created table names? I can't see how I can pass in a variable to the repository interface that contains the specific table name, which will always be a 'materials' entity even though the physical table name varies?
I'm currently in the process of creating a website/system and was wondering how I can create multiple versions of a table to then be used by many users. The reason for this is primarily due to the amount of information that is needed my each user. Another reason for doing so is a result of each information have been laid out to display the product code and other key information.
This is due to a main table setting a list of data for example prices of a product. To which the user then can set and store data in their own table to be used at a later date and referenced accordingly. Rather than creating multiple columns in the thousands I feel it would be better to simply create different versions of the table.
Instead of creating multiple table, why don't you not create seperate Views in Database based on your User and display that information in table.
Altought, its recommended to use the single same table, and add fields that allow to restrict some data for a particular user, there is some few cases that may be required to have several versions of the table, like the ones you mention.
I have work with a web app. that served several companies, with the same tables, fields, schemas, same web server & databased server, and yet the customers want it separated from other users.
Usually, you create several tables with the same schema, but different id. Your web app. must have a way to select which table or database you are going to use.
Be very careful with this approach, is very difficult to maintain, its better to use some programming techniques to control this scenario, like:
http://en.wikipedia.org/wiki/Multitier_architecture
That allows to have a lot of control over a database app. and allows to change a table or database with thesame schema.