The 3rd party web application is processing some information from the Microsoft Dynamics Nav database on Azure SQL. To access the table, the external table is created as a bridge from another database (also on Azure SQL).
Because of the performance reasons, the interesting part of the Nav table is to be mirrored to the 3rd party database -- using the custom data pump.
The problem is that the table ([...$Sales price]) has a composed key and not all of its parts is to be mirrored. The good news is that no record should be removed from the table (only INSERT and UPDATE operations). Another good news is that the new $systemId field was added as the unique key within the table. To combine it with the timestamp field...
If the records in the source table are not to be deleted, is it correct to mirror the data based on the timestamp field--to find newly inserted or updated records--and on the $systemId field--to recognize whether it is the UPDATE of the existing record, or INSERT of the new record?
Related
everyone!
We're using MS SQL Master Data Services to organize our enterprise master data and some of entities, we keep, consists of data, that we load from external sources almost as-is. We regularly update them using jobs or SSIS packages, placing data into staging tables ([stg].[<name>_Leaf]) and starting staging process using procedures, named as [stg].[udp_<name>_Leaf] as described in THIS and THIS topics about staging process in MDS.
Sometimes data, we import from some external source is presented as a flat table, just containing a set of rows, that we might want to reference in our other tables and then we load it and enjoy (in fact we place data into staging tables, call SP and let MDS proceed it in any, comfortable for server, moment, due to the main workload of staging process is running asynchronously, via Broker).
But there are a lot of other, ugly, but real-life cases, when data, that we load is presented as a tree, containing references to members, that we've not loaded yet and just going to place them into staging tables.
The problem is that in most cases we use automatic code creation function (and we cannot use not surrogate code), and we're not able to set member referencing's field value (where referenced's member code must be placed) to newly created member, before member is created and inserted into the base table and code is generated and set.
As I can see, we could resolve this problem, if we could reference staging member by staging table's ID, which is IDENTITY and assigned right after insert.
-OR-
If we could receive a callback from the staging process when data is placed into our base tables and codes are assigned. Then we'd calculate all references and update them (using the same staging process mech).
Currently, we use stupid not-very-elegant workaround, generating GUIDs and using them as Code value, when this scenario is.
Can anyone offer anything more enterprise? (:
When loading hierarchical data load the parent records into the staging table and then run the associated stored procedure to apply them to the entity table where they will be assigned the automatically generated code.
Next when loading the child records into staging leaf lookup the parent code using a subscription view of the parent entity.
When using automatically generate codes, I recommend you start at 10000 or 100000, as Excel sorts the codes as strings.
I am new to Dynamics FnO, and recently followed the articles to access data through oData, and was successful.
What I see missing in the data objects that I normally receive in integrations out of the Microsoft World is the created/updated timestamps.
I am trying to put a synchronous data flow from FnO to my NodeJs application, so that my app keeps polling data from FnO whenever there is a change. This can be achieved easily if there were timestamps with the data that flows in.
Is there a way to setup those timestamps somewhere?
You have to make sure that the underlying table that you are querying has the fields added on it, and also that the data entity you are accessing through odata has the fields setup up on it as well.
Make sure this is setup on the table:
And then you have to drag and drop the field(s) from the datasource field list to the exposed field list in the data entity:
After this, you will have these fields
I am making a user form in Delphi for documents tracking application. I am interested in functionalities input new entry (record) and view list by... (date, name of document, ID,...).
My problem is that I don't know how to implement these functionalities for more than one user. Currently, I have 5 users. Each user has a unique input data (record) fields (columns) and view fields (columns) of each user are also unique. There could be more users.
So, how to implement these functionalities for this form? How to assign different data (fields) for each separate user for input and view? That is what I don't understand. Is that distributed functionality of an application? If yes, how to achieve it?
Note that I don't want static assigning of a user in application's code, e.g:
if(username='user1') then {
input();
view();
}
else if (username='user2') then {...}
...
because, than, every time there is a new user, developer must go back to the application's code and hard-code it. That is not efficient and is a bad implementation. Rather, I want that to be dynamic (if that is the right term). How to achieve this?
Note: I am using dbExpress tool with MySQL DBMS with RAD Studio XE7 Architect.
If I'm correctly understanding what you are asking, it seems as if you are unfamiliar with the idea of tables/datasets which operate in a so-called Master-Detail relationship. These are very easy to set up in Delphi.
Once you get familar with M->D relationships, I think you'll realise that what you should have been asking about is how to set one up in your app, rather than the problem of hard-coding of individual users into your form.
In your case, what you are missing at the moment is a table of users' details. Let's call that the Users table. Usually this would contain their name, obviously, and some kind of unique identifier (best is a "Primary key" in the Users database table), but NOT, please, their password to access the db, especially not in plain text.
Once your Users table is created, you can create a display grid (TDBGrid) and input/editing form for it.
Then, if you don't have it already, you could set up a grid and editing form for users' documents (which I'm going to refer to as the Documents table).
Once that's done, the main thing left to do is to set up in your Delphi project a Master-Detail relationship between your Users table (the master) and your Documents table (the detail).
If you prefer you can have a single form with two grids, the Users grid and the Documents grid on it, and as you scroll through the Users grid, you'll see that the Documents grid shows only their document records.
The details of how to set up a Master-Detail vary somewhat according to the type of table/dataset you're using so you'll need to search online for the details of how to do it. Broadly, it's a matter of connecting a TDataSource to your Users table and setting the DataSource (or MasterSource) property of your Documents table to point at the Users TDataSource, and then setting a couple of other, table-type-dependent properties of the Documents table.
Every edition of Delphi since well before D7 has come with a demo app, "MastApp" which illustrates how you use Master-Detail relationship amongst a number of tables. I suggest you take a look at the MastApp for your Delphi version and then look into how to set up M->D relationships for the type of Delphi dataset you are actually using.
I am developing an Intranet application and have successfully integrated with Active Directory.
When we add a new customer I would like to assign a Customer Advisor from a dropdown list.
I am able to populate the dropdown list using the following
PrincipalContext pc = new PrincipalContext(ContextType.Domain, "DOMAIN", "dc=domain,dc=org");
GroupPrincipal group = GroupPrincipal.FindByIdentity(pc, "customerAdvisors");
ViewBag.Guid = new SelectList(group.Members, "Guid", "DisplayName");
I would like to then store the Guid of the selected user along with the Customer data in the database.
However, I am unsure of how to setup foreign key constraints in my Model as the table I am joining to is within Active Directory.
Do I need to create a separate Employee table within my DB and sync the required fields or is there a simplified way of doing this?
I've never done this but some quick research makes it look possible.
You could just save the Guid for your adviser on your Customer. The AD Guid can go into the Guid data type. You should be able to query individual users by using this method:
UserPrincipal user =
UserPrincipal.FindByIdentity(pc, yourUsersGuidAsAString);
The down side is that every time you want your customer adviser's info (like their name or email address) you will have to do a separate query to AD. Harder to use ORM.
In my application I have a different use case, but I have also integrated my application with AD. The route that I took was to save this information in my own DB instead of hitting AD every time. In large part because my architecture makes it hard to get to AD in the same way you can. Also it's easier to use ORM (like entity framework in my case) to pull in the information that I want. The downside to this is then you need to ensure that the information you have in your database is reasonably up to date with what's in AD.
You will have to make the judgement on which approach makes the most sense for your architecture/use case.
Hope that helps.
My app talk to webServer. At login, I pull down JSON and make up CoreData with 4 Entities (about 1000 rows each). The data changes on Server, So with every login, I have to update my existing CoreData.
What is the best approach to find out if records exist and insert new ones if need be?
To be smart on update (not blindly update every time), you need some intelligence on the server side.
One idea I would do.
Server has master table that records the timestamp of modified date of the 4 entities. It also has API to expose the master table. Every time change occurs to one of the 4 entities, master table's corresponding entry has to be updated as well.
You create the same copy of master table in application side as well.
On application launch, you query API in 1. and compare with the value in 2. to see if the timestamp has updated on the server side.
If YES, then download and replace the corresponding entity.
Another one which allows finer control.
Add timestamp column to the 4 entities on the server side. Every time entry is added/updated, the timestamp is updated.
Prepare an API for each entity that filters only newer items than the specified timestamp
On application launch, you query API in 2. and update.
The hole of the second approach is that it cannot handle deletion on the server side. Maybe you can combine something like the first approach to support this.