|
C# is a mighty tool 
Greetings from Germany
|
|
|
|
|
would of been funnier like this
string EntityID += new System.Text.StringBuilder("").ToString();
|
|
|
|
|
Humble Programmer wrote: string EntityID = new System.Text.StringBuilder("").ToString();
string EntityID = new System.Text.StringBuilder("").ToString()<blink>.Replace("", "");</blink>
This should make it faster;P
Smile: A curve that can set a lot of things straight!
(\ /)
(O.o)
(><)
|
|
|
|
|
DEATH TO THE BLINK TAG!!!!!
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
string EntityID = new System.Text.StringBuilder("").ToString().Replace("", "").Trim();
Just to remove any errant spaces ...
|
|
|
|
|
Good morning
Smile: A curve that can set a lot of things straight!
(\ /)
(O.o)
(><)
|
|
|
|
|
Ok, I come across stuff like this daily...but this one was the most recent
CREATE PROC foo<br />
<br />
BEGIN TRANSACTION<br />
<br />
SELECT @id = id FROM ...<br />
<br />
IF @id IS NOT NULL<br />
BEGIN<br />
...do some stuff, there is NO ROLLBACK in here or error checking...<br />
COMMIT<br />
END<br />
else<br />
ROLLBACK
It's just so...useless. We only ever rollback if we didn't do anything?
|
|
|
|
|
That makes the ROLLBACK extremely fast. 
Chris Meech
I am Canadian. [heard in a local bar]
Stercorum pro cerebro habes. [Cicero]
|
|
|
|
|
Chris Meech wrote: That makes the ROLLBACK extremely fast.
Smile: A curve that can set a lot of things straight!
(\ /)
(O.o)
(><)
|
|
|
|
|
GibbleCH wrote: It's just so...useless. We only ever rollback if we didn't do anything?
Defensive coding at its finest.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
GibbleCH wrote: It's just so...useless. We only ever rollback if we didn't do anything?
Well, maybe you didn't see a "set XACT_ABORT on" statement buried in the code? If that is set, then rollback is automatic whenever an error occurs.
|
|
|
|
|
Then get rid of the existing ROLLBACK.
|
|
|
|
|
This has a real drawback: you wont see that the code is poor. 
Greetings from Germany
|
|
|
|
|
Last Friday, I had to visit the bank to open a Term Deposit account. Just about a month back, I had requested the bank to update my communication preferences to the updated and corrected address. They confirmed but again ATM records showed the old address. They wanted one more application form towards that updation.
And for Term Deposit, again they retrieved and showed my old record. I just got irrititated and asked them about their 'sick' database system that really sucks or whether it was the nonchalant attitude of the hostile staff, they actually wanted to investigate into the issue.
The banking application seemed to have gleaming coding horrors.
1) There are two identifiers for a customer in thier system. Account Number and a CustomerID. For every relationship (Savings Account, Current Account, Term Deposit) that a customer opens, it actually copies and stores the data separately. Now, the teller has to update everything individually.
2) Give account number, it fetches from one table. Give CustomerID and the address is fetched from different table.
And given the number of customers in the bank, it means so much of data storage wasted besides the performance penalty on the system.
The software companies that take up banking projects which are interested in taking a fatty cheque home from the bank just raises the eyebrow whether they are really committed in giving a quality product? 
|
|
|
|
|
My Wife opened an online bussiness account with a local bank. They insisted that someone come out and train her how to use it.
The reason for this was not a training issue, rather the trainer had to change all the security settings on IE to get it to work (cache https pages, etc). I wouldnt have minded if they had:
a) Told us what they were going to do
b) Didnt pretend they hadnt done it until i said i knew they changed something and would go to the press.
|
|
|
|
|
|
Good Catch
|
|
|
|
|
|
Nice reply!!
Cheers
You have the thought that modern physics just relay on assumptions, that somehow depends on a smile of a cat, which isn’t there.( Albert Einstein)
|
|
|
|
|
I voted you 8 for that!
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->ßRÅhmmÃ<-·´¯`·.
|
|
|
|
|
It often happen when the systems are decided by the different big shots who doesn't need to maintain the system.
The end result is all the middle systems are required to compensate for that (different ID, different naming of saving/current account, XML that doesn't follow XML standard).
You are not alone. 
|
|
|
|
|
Vasudevan Deepak Kumar wrote: There are two identifiers for a customer in thier system. Account Number and a CustomerID.
That makes sense because a customer could open multiple accounts, account number alone won't be enough. The same thing in my company (insurance), we use both policy number and customer id.
Vasudevan Deepak Kumar wrote: For every relationship (Savings Account, Current Account, Term Deposit) that a customer opens, it actually copies and stores the data separately.
Again, this can make sense in the banking business. For us, there is coverage information for each policy. But when a customer files a claim, the coverage at the time will be copied into the individual claim file record. There could be business/security reasons for bank to maintain separate addresses for different accounts.
Vasudevan Deepak Kumar wrote: Now, the teller has to update everything individually.
That does not make sense, but you never know. If the bank is still usign mainframe like we do, automatically update everything may not be so easy.
Ok, I am done with defending stupid systems/programmers today.
|
|
|
|
|
Xiangyang Liu wrote: That makes sense because a customer could open multiple accounts, account number alone won't be enough. The same thing in my company (insurance), we use both policy number and customer id.
I understand. With biggies and for enterprises who need to have accounts separately for every purpose like 'Expense', 'Payroll' etc and for each department, this might befit. But for guys like me who just maintain about the Monthly Minimum Balance and rarely when there is some fund, just thinking of saving for the rainy day to put it into a Fixed Deposit and with a specific clause in Term Deposit like 'Credit Interest to Savings Account' and all other KYC (Know Your Custoemr) guidelines as applicable from the savings account, I think this would be like a laughing stock. Isn't it?
Furthermore, in these regions, the Term Deposits had to be managed only in the same bank and most banks stipulate that a savings account is mandatory first to open a Term Deposit.
Xiangyang Liu wrote: If the bank is still usign mainframe like we do
It is a typical client server system and I don't think there aren't big mainframes being used over these places.
|
|
|
|
|
[start quote, since there seems to be no button to automatically quote, at least not in Opera.... nor a preview button]
> With biggies and for enterprises who need to have accounts separately for every purpose like 'Expense', 'Payroll' etc and for each department, this might befit. But for guys like me who just maintain about the Monthly Minimum Balance and rarely when there is some fund, just thinking of saving for the rainy day to put it into a Fixed Deposit and with a specific clause in Term Deposit like 'Credit Interest to Savings Account' and all other KYC (Know Your Custoemr) guidelines as applicable from the savings account, I think this would be like a laughing stock. Isn't it?
[end quote...]
I think it would be a real laughing stock to have a different database/system design for "biggies" and "small" customers.
Don't you think so?
If they have to implement the more general and complex design for some customers, then it makes sense that they would use it for all customers. To maintain two totally different systems would be a total disaster and a waste of effort.
Oisín
|
|
|
|
|
Can't blame the software developers or the software development companies for it. They just do what they've been asked to do. I can tell you clearly that this has happened because of one or a bunch of half-wit managers who has given improper inputs to the developers.
It's funny that always the developers are the underdogs, no matter what.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->ßRÅhmmÃ<-·´¯`·.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
