MMPD Data Sync Best Practices - D-Tools Forum

fryeguy · 09-22-2009, 10:26 PM

I have been using D-Tools for many years but with a limited number of active seats running concurrently and sharing a common database. Currently two users have full administrator access to manipulate data and sync data. Two other users can download data and manipulate local data but they cannot send data back to the server. I have been struggling just to keep the two full rights users' data properly synced (i.e. we constantly have data conflicts). Now the goal is to add our purchaser into the mix so he can help update pricing. There is also a request to give the other users full access to data syncing. Call me crazy but I think this is a bad idea.

Can anyone comment on their success in this area and provide a few tips on expanding the number of users who have two-way sync rights and how to limit/solve data conflict issues?

Maybe I am just a little paranoid about controlling my data but somehow I feel like things could get ugly...

**Dave Kirn** · 09-23-2009, 06:42 PM

My opinion is that you should only have one person that controls your data. Everyone has their own way they think items should be entered, therefore it is best to just have one person control it.

fryeguy · 09-23-2009, 08:08 PM

I would agree. How does that look for you in production? Do you have only one person creating proposals? In the real world when proposals need to be turned around in hours and not days, how do you manage the need for new and/or revised items?

My biggest concern is just what you said,

Quote:

Everyone has their own way they think items should be entered

and this fact, even with a "data best practices" policy in place, leaves me thinking that multiple points of data entry will do nothing but cause problems of inconsistency and errors in data.

**Dave Kirn** · 09-23-2009, 10:09 PM

I am the GateKeeper of our database. No one else can enter data. I have other people that create projects however if there is new data required they send me the request and I enter the required data.

We have two different types of data - Proposal Data and Production Data.

Proposal Data is only the product information that would be required to produce a proposal: Manufacturer; Model; Product Image; Category; Type; Description; Unit Price; Phase; Labor Hours. This is the only information that is required to produce a proposal so it is pretty easy to get the minimum data entered so that a we can continue working on the proposal.

Production Data is the entire product data including Specifications, Accessories, and custom stencils if necessary.

Since we provide data for other D-Tools users we have a pretty extensive database so we do not have a need to add alot of products, however there are new products released everyday so this is the best process that I have found.

When I was a dealer using D-Tools I actually tried to let two of my Project Mangers maintain data for about 2 weeks and then I had all the issues that you are talking about and our data was no longer consistant. I have maintained total control of my data ever since.

Hopefully that makes sense. If not or if you want to discuss further feel free to send me an email or give me a call.

fryeguy · 10-22-2009, 11:41 PM

I am writing a "database best practices" one page paper for our team. Any thoughts?

**Ryan Brown** · 10-23-2009, 06:17 PM

Hey Kevin,

We use a standards spreadsheet broken out by Category and Type. Within each of these we assign Phase, Estimated Labor Hours as well as recommended accessories for these products.

Taking it a step further - you should define standards for all the I/O naming conventions (ie: what do you call a component video connection and is it entered as one I/O Entry or as three?)

Sometimes it is not realistic to have one person manage the database, however ideal of a situation that is. We've found that through communicating standards you can minimize (not eliminate) inconsistencies. If taking this approach it is effective to have one person be the database Quality Controller whose responsibility it is to review data on a regular basis. MMPD Product Grid makes this much easier than it has been in the past.

Just a few thoughts.

ChristianB · 10-24-2009, 09:57 AM

Ryan, on that note: Can you use an unapproved product in a proposal? Thought being that a salesperson can add a product when he needs it for a proposal, then Quality controller can list and review those products later on.

**Dave Kirn** · 10-24-2009, 02:32 PM

Christian -

You are able to add "unaproved" items into a proposal. In order for them to show up in the list you need to select the "filter" button on the Data Matrix and change from the default setting of "show only approved products" to "show all products". However allowing employees to use the unapproved products kind of eleminates the purpose of and unapproved product.

ChristianB · 10-24-2009, 08:56 PM

I know that it's not an ideal situation, but I need a solution for the sales guys that works at night finishing proposals or tenders and needs to add new products. We are operation only in the commercial market and in complex cases we need products that are quoted on a project to project basis. Of course a limited number of users will be allowed, maybe 5 of 25. I was thinking of marking the prorduct they add as unapproved so it will be easy for the quality controller to revise them afterwards.

**Ryan Brown** · 10-25-2009, 12:35 AM

Hey guys it is my understanding that items marked unapproved on a local machine do not sync off that machine to the server, they remain local only. The idea being that a db manager keeps it local until he's ready to send it out to everyone to use.

Can anyone confirm?

Christian, maybe use a Keyword1 = Unapproved or something. This can be easily filtered in the Product Grid (to locate these items and verify the data) and should not affect other areas of the software. Just a though, haven't fully thought it through. It's Saturday I need to get off here!