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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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,
JRB-Bldr
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,
JRB-Bldr
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+company
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.
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+company
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.
ASKER