Especially in "Relational Database Systems" Like Ms Access or SQL Server

 

Especially in "Relational Database Systems" Like Ms Access or SQL Server

Devising a unique key is not the responsibility of Outlook, however an email address is typically suitable, each contact has a unique email address. However a person's email address can and does sometimes change. This is why we have concepts like account number or employee ID or user ID or user name. The problem domain usually dictates the nature of the unique key.

 

Actually I am building a software tool for a Milk Vendor. In India, still many doesn't have a mobile phone at least, then only email.

 

I am thinking of the following:
Cstr(replace(".",cdbl(Now(),""))
But the problem is Outlook lacks Replace() in the auto-value property of a custom form.

 

I am thinking of the following:
Cstr(replace(".",cdbl(Now(),""))
But the problem is Outlook lacks Replace() in the auto-value property of a custom form.

Whatever kind of unique key you choose, the individual themselves must know it or be able to get it. There's no reason you cannot use phone or email address though. Just have a column for ID Type - which could be 1 (email) or 2 (phone) for example.

How does the business owner himself identify customers? if he has a way then you should use that, the closer your solution mimics the actual business the better it will be.

 

Whatever kind of unique key you choose, the individual themselves must know it or be able to get it. There's no reason you cannot use phone or email address though. Just have a column for ID Type - which could be 1 (email) or 2 (phone) for example.

How does the business owner himself identify customers?

Auto-incremented ID in manual ledgers

 

Auto-incremented ID in manual ledgers

I see, well I'd seriously consider doing it the same way, unless he wants a different way, the more you mimic his real business processes the better, be sure to model the solution on his world. I've seen solutions (big ones too) to business problems that try to force the business to work in a fundamentally different way and that should only be done if the business itself really wants that.

I'm assuming that once the new system is accepted, there will be no more manual ledger, if he continues to use that and the new system things get complicated, these are the kinds of things to spend time on, the technical design should not be the first concern even though that's tempting sometimes.

 

Auto-incremented ID in manual ledgers

Also if that ledger has thousands of customers defined already, then part of this solution will be the data take on, migrating the data in the ledger into the new system, that needs to be thought about as well as who will do it, ideally he or a member of his staff will do it, but don't leave it until the last minute! Often business owners have no grasp of these issues and just have expectations that "it will all just work" managing the business's expectations is all part of this profession.

 

sure