Reply to: Bit of a technical question but opinion is great

[LondonManc]

did all of that when I migrated the world off Dynamics. We pressed a button & waited normally chatting & drinking tea with the PM. Migration was done on a Friday night.

This system however is not mine. Fewer users, fewer opportunities & customers and its taken 6 people so far.

Ah, well that's different. You'll need to do the job properly. Shame.

[vetran]

What's the source of your copy of data and what's the target?

What is the master of the data going to be?

Unless you have a mechanism to align changes made in any system then there isn't a lot of point doing the work at all.

The registry approach is OK but I always prefer a master hub single maintenance approach if possible. Lock down any functionality that allows changes elsewhere.

Whichever you go for, you're doomed.

did all of that when I migrated the world off Dynamics. We pressed a button & waited normally chatting & drinking tea with the PM. Migration was done on a Friday night.

This system however is not mine. Fewer users, fewer opportunities & customers and its taken 6 people so far.

[GB9]

Big picture thinking? YMMS

Think only about the bit of work that you've been brought in for. It leads to disjointed development and allows you to upsell at a later date.

Good point, well made.

[LondonManc]

What's the source of your copy of data and what's the target?

What is the master of the data going to be?

Unless you have a mechanism to align changes made in any system then there isn't a lot of point doing the work at all.

The registry approach is OK but I always prefer a master hub single maintenance approach if possible. Lock down any functionality that allows changes elsewhere.

Whichever you go for, you're doomed.

Big picture thinking? YMMS

Think only about the bit of work that you've been brought in for. It leads to disjointed development and allows you to upsell at a later date.

[GB9]

What's the source of your copy of data and what's the target?

What is the master of the data going to be?

Unless you have a mechanism to align changes made in any system then there isn't a lot of point doing the work at all.

The registry approach is OK but I always prefer a master hub single maintenance approach if possible. Lock down any functionality that allows changes elsewhere.

Whichever you go for, you're doomed.

[MrMarkyMark]

If in doubt, code in vague complexities that only you understand and then don't document them or even comment the code, other than that you built it and your email address so that you'll get repeat business.

Must be similar to the guy that managed to last 25 years contracting here.

A totally gilt edged job.

I believe they managed to get him out and 2 months later he was back

[vetran]

FTFY.

Lovin that!

[LondonManc]

FTFY.

If in doubt, code in vague complexities that only you understand and then don't document them or even comment the code, other than that you built it and your email address so that you'll get repeat business.

[vetran]

Who cares what you requested 3 years ago. Here's what you should do today.

If I was refused 3 years ago what makes you think I'm going to get it fixed today in the bits I have no control over.

[billybiro]

hardly I know what the answer is. I just needed the love.

A is the only answer if you practice mortgage-driven development and are keen to ensure many more years worth of contract renewals.

I thought you guys needed a laugh.

FTFY.

[MrMarkyMark]

Who cares what you requested 3 years ago. Here's what you should do today.

Agreed, lets not look back and learn from our mistakes.......lets just look forward

[WTFH]

If only that was what I requested 3 years ago.

Who cares what you requested 3 years ago. Here's what you should do today.

[MrMarkyMark]

The usual bulltulip logic that you get is that it takes too long to do it properly.

And......then that bulltulip decision bites them back for years afterwards

[LondonManc]

It's a wonder these amateurs stay in business.

And it takes extra stupidity to dispute the need for unique keys even when the reasons are patiently explained.

The usual bulltulip logic that you get is that it takes too long to do it properly.

[OwlHoot]

.. Then get told by the one who asked you to do it (who doesn't understand why records need an identifiable key) & Your Boss who is non technical that you are over complicating things and you think WTF??? ...

It's a wonder these amateurs stay in business.

And it takes extra stupidity to dispute the need for unique keys even when the reasons are patiently explained.