• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 448
  • Last Modified:

Non-typical way of creating a client ID

C# Windows Form.  When we create a new client ID for our client table, we would like to be able to select a valid code from the codes table and then have the sytem generate the unique 3 character sequence for the code.  For instance, 2 valid codes are 10 (reinsureance company) and 20 (other company).  In our current Visual FoxPro system the user can type 10 in the text box or click the pickbox icon to the right of the text box to select 10 from the list of valid codes.  Either action triggers a system routine that generates the next 3 characters and displays it in the text box.  Example:  for the code of 10, the next available 3 digits are 463, so the new client ID would be 10463.  I am new to C# and cannot find a simple way to do this to emulate the current routine in Visual FoxPro.
1 Solution
You should ask moderator to add C# forum to your question.

IMHO there is no need to transfer existing Visual FoxPro application to C#. The cost of staying in VFP is almost none. VFP apps will run another 15 years whereas the technology can change significantly so you'll think what to do with this C# app soon... And what's more in 15 years? Virtual machines will be as fast as todays hardware so today's applications will run unchanged. Yes, the UI will change and user needs will move probably.

Visual FoxPro is still the best tool to develop desktop applications on Windows platform. Client-server is also the target topology for FoxPro. Of course, if you need internet or mobile application then you should think about the switch to another platform.

To port the VFP app into a cloud would also be an option - see http://www.foxincloud.com/index.php.
joycekinzlerDeveloperAuthor Commented:
This is an encouraging response.  Our current FoxPro product has taken 20 years to evolve to the great product that we have right now.  We have already taken the steps to move all our data to SQL server and to depend on FoxPro remote views and stored procedures to manage the data throughout the system.  What a bummer to have to start all over with a new UI.  I appreciate your words -- they have certainly got me thinking. Thank you!
IMHO there is no need to transfer existing Visual FoxPro application to C#.

I will second Pavel's comment with a caveat...

There are GENERALLY no FUNCTIONAL needs to transfer existing Visual FoxPro application to C#.

Typically the incentive to change application development languages is due to Business Requirements not Functional Requirements.  
If so, then you cannot get around it - although you might try to 'educate' those creating the Business Requirements to the possible 'holes' in their reasoning.
But if others FORCE the change, then go ahead and get on board.

However it is quite often that those 'Forcing' the change are doing so because they don't really fully understand the power and capabilities of Visual Foxpro - or they are somehow prejudiced (misguidedly so) against it.

Alternatively (as Pavel has mentioned) if you need to migrate your application to the web, other issues might come into play.

Good Luck,
Olaf DoschkeSoftware DeveloperCommented:
Is the problem really to concatenate two parts of a number in C#? If that is already causing you headaches, then how do you cope with programming overall?

Now, I don't want to be cynical about it, but you have to explain what is really the problem. The surface of the problem you show is no problem. I would rather do this within the database, anyway. And the best thing in SQL Server would be two seperate fields companytypeID and companyNo, and have a computed field companyID with the value being  companytypeID*1000+companyNo.

And to calculate the next companyNo you do

declare @companyno int;
Select @companyno = Max(companyno)+1 from companies where companytypeID=10;

Doing that in an instead of insert trigger you intercept creation of any new record and automate creation of the companyno, then do insert into companies (....,companyno,...) values (...,@companyno,...), even simpler doing that in a stored procedure you can call it as default value expression for companyno and return @companyno.

I'm not sure if there even is a way to have a sequence per group.

And overall you're giving an example why IDs should always be surrogate keys and not be composed of meaningful ids or other fields. It's totally ok to make the companytype an attribute of the company, but that's a normal foreign key to a companytype table. And you may from time to time need to know the number of companies of a certain type, but you don't need the comanyno as a business information, do you? To list companies in the historical order of you working with them, store a datetime of the insert of the company.

So your problem simply is a wrong database design, if I'm very strict about it.

I do also use barcode numbers composed of two or three detail infos, that are then extracted from a barcode scan to reidentify data, eg a certain test sample. But that composed number then is done out of barcode restriction (EAN12 for example, not yet QR), and not used as primary key.

Bye, Olaf.

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Tackle projects and never again get stuck behind a technical roadblock.
Join Now