I'm trying to figure out what could be the best solution for this use case:
there is a need to track each field changes in agreement entity. So when someone makes update for any field they must set when this is going to be applied (can set date in future or past). And later it should be possible to filter by some field's value in the past for specific date interval. So basically it's needed to have history of each field and apply correct value according to current date.
At first glance, it's possible to use event sourcing when entity is built from events on write side and for read side it could be used snapshots so on each new change for entity would be rebuild in SQL database table for quering operations.
Is there any simpler solution for this case?
Yes, ES could be an appropriate solution for your problem. You track all fields changes as separate events. And it would help if you create various read models according to your requirements.
If you need to store the history of each field change, you probably have a read model for this purpose and another for your last or per version snapshot of your read side entity.
Noice: You create your read models according to your current or future requirements. Maybe you need a new read model after 6 months, So you create another read model. BTW you can achieve this by using event sourcing.
It maybe seems a trivial question, but how to design the problem to SQL?
I have a document containing tasks inside.
Each document is per day and each task the have description, complete properties.
I want to be able to provide a page to the user where he can see the tasks of the document and be able to mark if it's complete.
Also, I want to provide the user the ability to edit/add or delete tasks without impacting the previous documents.
Of course, I start from the basic create a tasks table and docs table and docs_tasks for the relationship, but how to design the edit/add or delete without impact the previous docs (for search and archive purposes)?
I want to create an on-demand process of some kind in Dynamics CRM 2013 that will run on multiple records of the same type. The process will create an equal number of records of another type, and all will relate to the same parent record. I can imagine how a workflow would be used to create the new child records but I am not sure how I could create the parent record and associate it with the child records.
If you're running on multiple records, then I presume your are starting from a gridview of some sort. If that's the case, then the solution is easy. Just create a custom ribbon button that accepts the selected records as a parameter, and runs a custom javascript. That will accomplish what you need in a nice elegant solution.
Because it's running javascript, you will have full control to be able to do everything you need. One of the features of ribbon buttons, is they can receive the selected records in a parameter as an array.
But if you don't want to do all the work in javascript, you can have the script pass the parameters to a custom Workflow or Action.
As its already been mentioned, a workflow won't be able to do this alone, because it can only run on a single record, and cannot accept multiple records as an input parameter.
Jason I think the point here is to automate the process. Lee you are correct in your assessment that creating the work order with a workflow step is easy to do while creating the child work order items is either difficult or impossible. Even if you managed to hack this together with several workflows triggered by different events during the process the end result would be a UX/maintenance nightmare.
The simplest and best solution is to have piece of plugin logic that you trigger with your workflow. This plugin code would create a new work order and associated work order items based on the context of the service you run the workflow against. If you would like for this action to be triggered by a database operation instead of manually triggered this would be simple to do as well.
You aren't going to be able to do this via a CRM dialog because it can only run against one record. You can accomplish this fairly easily by leveraging existing CRM functionality:
If it doesn't already exist, create a field in your service entity (the Work Order Item) called new_MasterWorkOrder (or something similar) which is link to a Master Work Order entity.
Create your master record - this would be your Overall Work Order.
From your Work Order Item record entry listing, select all the items you want to add to the Master Work Order record created in the previous step. Alternately, you could use an Advanced Find to locate the target records.
Click the Edit button to initiate the CRM bulk/multi-record edit form.
In the new_MasterWorkOrder field, select the Overall Work Order previously created.
Save.
Once the process complete, all of the Work Order Items you selected will now be linked to your Overall Work Order.
It sounds like you might a need a step before this to create a Work Order Item from selected Service entities. You should be able to accomplish this easily by having a workflow which runs takes in a Service entity as a parameter and builds a Work Order Item from it. Once you have these built you can link them to an Overall Work Order using the process above.
Presently, I'm tracking changes to all of my tables using SQL Server 2008 Change Tracking. Everything works out of the box just fine. However, an additional complexity is that the application reading these changes needs to make a change to a date column on each table that is being tracked. Changes in my application are like triggers to tell me that I need to send out additional data. This could cause an endless cycle if not managed.
There's a sent date that gets filled in after each change is read.
Is it configurable at a database/table level to ignore an individual column on a table so that versions/changes are not tracked when that column is modified?
Using change tracking, there's two ways but both involve merely filtering the results; there is not a way to limit the change tracking by column.
1) Filter by context
The following link shows how to change the context for when an application changes data. If you change the context specific to what is making the changes, you can then filter it by that when you query. http://msdn.microsoft.com/en-us/library/cc280462(v=sql.105).aspx
2) Filter using the columns updated mask
In addition, I have to admit that I roll my own change tracking still. I have scripts that I execute to autogenerate code triggers. They can be customized to prevent non-changing updates (i.e. a row update that changes no fields you are interested in), plus they allow me to fully control things. I can track which fields I want, plus I can move all of my tracking/default fields (such as suser_sname()) into the tracking table so that the day to day business tables are kept slim. If you are interested in this option, reply as such and I'll post the code to autogenerate the triggers and tracking table for a given table name.
I recently acquired this book from Microsoft Press. I currently have Office Enterprise 2007 (Access included) and have firmly decided to convert my Informix-SQL app to Access 2010. However, I'm not experienced with VBA, Macros and several other functionality my app needs. This is going to be a new learning process for me, but I must modernize my 20 year old char-based app and take advantage of new features. I have begun defining my tables and columns, but not the relationships. With INFORMIX, I join a serial (autoincrement) column with an INT column in another table. Now when I display a customers master row, I would like to automatically display all of the transactions associated with that customer in a sub-form and have the ability to add, update, query, delete on either tables. Can this be accomplished with A'10?
EDIT: OK, this is what I have done so far, defined tables and relationships:
there are more validation lookup tables to follow, but these are the main tables. So if now I create a form and specify the CLIENTES (customer table), LOTES (lot table), ARTICULOS (item table) and TRANSACCIONES (transaction table) it will create a CLIENT table as the master form and the other child tables as subforms on one screen?
Also, the reason I created a lot table is because when customers pawn or sell items, the pawnshop groups all these items into one lot, calculates the total loan or purchase amount, stores it all under one transaction and prints the ticket with a description of all the items and total amount. So I want the ability to say, if customer defaults on interest payments or does not redeem pawn, then customer forfeits all items and pawnshop may choose to sell some items to gold refinery and/or transfer other non-gold items to inventory to sell to the public, so would the above ER be adequate for this capability?
I also want to ensure that every row in every table has the same store_ID (company ID) while users are working within a specific company, as this system will be multi-company and there will be consolidated reports, etc.
This type of setup can be accomplished in any version of access going back to 1992.
The way you model these classic one to many relationships in access is to base the parent form on the parent table (note I said partent table, not a query – I going to repeat this again: you do not need a query that joins the data for you). You then create what is called a continues form based on the child table. You now have two forms, and you then can simple drag + drop in the form for the child table into the above parent form, and you are done.
In fact, if you design and setup the relationship correctly in the relationships window, then if you use a wizard to create the form, it will actually build and automatically insert a sub form for you.
So, there is some several interesting issues about the above process that you should know As I pointed above, you don't have to build any SQL query at all. You don't have to write sql to join together the data. Access will do all of this for you, and do it without any code.
So, when you navigate records in the main form, the child records will be automatically displayed and filtered for you in the sub form. (and if you add or delete or edit those child records, the correct relationship key is inserted and maintained for you, again done without writing any code at all).
In the following form, we have a classic accounting funds distribution example. In this example we are tracking membership donations. So, the top part of the form is one record based on the master table and is the donation event. I then created an continuous form. When dropped into the main form, it becomes a sub form. That form is the one on the left side, and it simply allows me to enter a list of members who donated for the above event.
The form looks like:
At this point the form will work without any code having been written.
In fact the above form I have the one main record, on the left side I have many members who made a donation. However, I also needed to split out each donation for those memebers on the left side to an to particular account for accounting purposes. (a classic check spliting that you see in just about every accounting package these days)
So the above models a one to many and then the many members also split out into many different accounts for each donation. A really incredible powerful setup, and one that has almost no code.
So, in the above I'm really doing three tables deep as a model. |And, to be fair, the right side (donations split into accounts) did need one line of code to update correctly, as access does not do this for me when you go 3 tables deep.
However for the most part, to model these classic parent to child table relationships in access, you don't need to write any code at all. You use a main form and then for the child table, you insert a sub-form based on the child table.
And as noted if you set the relationships up correctly, access will automatically stitch the two together for you, and maintain the relationship for you. So display of the child records belonging to the one parent record will display for you automatically. And this ability includes you to edit and delete and add those child records. And, thus as you navigate to a new reocrd, all of the child records and information will automatically be refreshed for the next form.
In other words all the above can be done without building any SQL queries, and not one line of code is required.
Unfortunately Stack Overflow works great for asking a question and having an answer. However, a serious of Q + A that builds on previous question we much find that StackOverflow REALLY breaks down here. I will give this a shot, and with all due respect to the great stack overflow, I am temped to suggest you try a forum based system as opposed to so. Perahps Utter access, or even the access dev forum here:
http://social.msdn.microsoft.com/Forums/en-US/accessdev
Anyway, lets see what we can come up with. I should also point out that your table design and how to relate those tables is not really a access question but simply that of database design. How this should be laid out will be the same for MySql, Oracle, FoxPro or in fact just about ANY relational database system that we had in the last 20+ years in our industry. So, this is not really a access question when you ask about how a database is to be setup.
Ok, lets see. In the above you have the LOTES table attached to customers. If you WERE going to attach (relate) the LOTS table to a customer, then you don't need the store_id in the LOTES tables since the table is a child to that customer record. Anytime you can go up to the parent table to get that information, you don't need to repeat it in the child table(s). So, that customer record you are thus relating back to already has the store id and you be able to get at that store id value any time since it is a relation (that is the whole idea of a relational database, you don't have to repeat data over and over again).
And, as you have it now, the same advice applies to the two child table to LOTES. Again they don't need the store id since by you above design they are already attached to the LOTES table which in turn is attached to the customer table where the store id is. So, in your current design ALL of the child tables below customer can and should and would have the store_id removed.
However, the above I suspect is not what you looking to accomplish here. It is quite likely that LOTES records belong to a store. If that is the case, then you want LOTES table to be child of stores.
You thus should have STORES->LOTES
The only part not clear here is if your design is going to allow one customer to be attached to more then one store. If this is a very rare case, then perhaps you adopt a easier design that either forces you to enter the customer again, or even via some copy code. While this breaks normalizing here often there are some issues like if the shipping address is going to change for different stores for the same customer, then often you save a lot of code and design issues by not normalizing in this case.
However, if you need this feature, then the reverse is also true and there is MANY advantages to normalizing this data correctly, but often more desing work up front.
If you really do want customers to have more then one store, then you need a table called tblCustomerStores. You will attach this table to customers as a child table, and this this table will have the store_id. You can then attached all customer transactions etc. to this child store table. And this Customer store table might even include perhaps payment type and deliver preferences (if they vary from store to store for example).
So, you start at
Customers->customer stores->Transactions->
And, it not quite clear what is in table transactions, but it possible that everthing else belongs below the above trans table.
And, it not clear if Articles are attached to a particular transaction or not? If they are, then articles for thus be a child of transactions.
I thinking more of
Customers->customer stores->Articles->lots
And you want Customers stores->Tranascation
And you want Customers stores->Articles
So, I think you are currently going too many tables deep. Just keep in mind that you can relate many table to the parent table just like you have in your diagram, but I think what you have it not what you are looking for