Search Results

Search found 6 results on 1 pages for 'konerak'.

Page 1/1 | 1 

• US Bank Routing Number and BIC/SWIFT

  - by Konerak

  I know it is a bit offtopic, but I've been having a hard time finding more information to this question, and since this site is visited by a lot of people from the United States, you guys might know/find the answer more easily. Banks in europe each have a SWIFT Number, while US Banks use Routing Numbers. This leads to following questions: Does each bank in the US also carry a BIC number? (SWIFT) Is there a 1-1 relationship between BIC/SWIFT and Routing Numbers? Is there a list of these numbers somewhere? Background information: We're adding international payments to our bookkeeping application. Users can add international suppliers, but my boss prefered not to change the current supplier table but to have the ROUTING NUMBER in another table, with as PK the BIC. I'm wondering if BIC is a valid choice, or if it should just be BANK ACCOUNT NUMBER.

  Read the article

• Perl equivalent to Java's "throws" clausule.

  - by Konerak

  Is there a way in Perl to declare that a method can throw an error (or die)? I always loved how in Java, a method could handle an Exception and/or throw it. The method signature allows to put "throws MyException", so a good IDE/compiler would know that if you use said method somewhere in your code, you'd have to check for the Exception or declare your function to "throws" the Exception further. I'm unable to find something alike in Perl. A collegue of mine wrote a method which "dies" on incorrect input, but I forget to eval-if($@) it... offcourse the error was only discovered while a user was running the application. (offcourse I doubt if there is any existing IDE that could find these kind of things for Perl, but atleast perl -cw should be able to, no?)

  Read the article

• OT: US Banks: Bank Routing Number and BIC/SWIFT

  - by Konerak

  I know it is a bit offtopic, but I've been having a hard time finding more information to this question, and since this site is visited by a lot of people from the United States, you guys might know/find the answer more easily. Banks in europe each have a SWIFT Number, while US Banks use Routing Numbers. This leads to following questions: Does each bank in the US also carry a BIC number? (SWIFT) Is there a 1-1 relationship between BIC and SWIFT? Is there a list of these numbers somewhere? (background information: we're adding international payments to our bookkeeping application. Users can add international suppliers, but my boss prefered not to change the current supplier table but to have the ROUTING NUMBER in another table, with as PK the BIC. I'm wondering if BIC is a valid choice, or if it should just be BANK ACCOUNT NUMBER.)

  Read the article

• Perl equivalent to Java's "throws" clause

  - by Konerak

  Is there a way in Perl to declare that a method can throw an error (or die)? EDIT: What interests me the most is a way to get the compiler or IDE to tell me I have an unchecked exception somewhere in my code. I always loved how in Java, a method could handle an Exception and/or throw it. The method signature allows to put "throws MyException", so a good IDE/compiler would know that if you use said method somewhere in your code, you'd have to check for the Exception or declare your function to "throws" the Exception further. I'm unable to find something alike in Perl. A collegue of mine wrote a method which "dies" on incorrect input, but I forget to eval-if($@) it... offcourse the error was only discovered while a user was running the application. (offcourse I doubt if there is any existing IDE that could find these kind of things for Perl, but atleast perl -cw should be able to, no?)

  Read the article

• Can the Perl compiler tell me if I have an unchecked exception in my code?

  - by Konerak

  Is there a way in Perl to declare that a method can throw an error (or die)? EDIT: What interests me the most is a way to get the compiler or IDE to tell me I have an unchecked exception somewhere in my code. I always loved how in Java, a method could handle an Exception and/or throw it. The method signature allows to put "throws MyException", so a good IDE/compiler would know that if you use said method somewhere in your code, you'd have to check for the Exception or declare your function to "throws" the Exception further. I'm unable to find something alike in Perl. A collegue of mine wrote a method which "dies" on incorrect input, but I forget to eval-if($@) it... offcourse the error was only discovered while a user was running the application. (offcourse I doubt if there is any existing IDE that could find these kind of things for Perl, but atleast perl -cw should be able to, no?)

  Read the article

• MySQL Datefields: duplicate or calculate?

  - by Konerak

  We are using a table with a structure imposed upon us more than 10 years ago. We are allowed to add columns, but urged not to change existing columns. Certain columns are meant to represent dates, but are put in different format. Amongst others: * CHAR(6): YYMMDD * CHAR(6): DDMMYY * CHAR(8): YYYYMMDD * CHAR(8): DDMMYYYY * DATE * DATETIME Since we now would like to do some more complex queries, using advanced date functions, my manager proposed to d*uplicate those problem columns* to a proper FORMATTED_OLDCOLUMNNAME column using a DATE or DATETIME format. Is this the way to go? Couldn't we just use the STR_TO_DATE function each time we accessed the columns? To avoid every query having to copy-paste the function, I could still work with a view or a stored procedure, but duplicating data to avoid recalculation sounds wrong. Solutions I see (I guess I prefer 2.2.1) 1. Physically duplicate columns 1.1 In the same table 1.1.1 Added by each script that does a modification (INSERT/UPDATE/REPLACE/...) 1.1.2 Maintained by a trigger on each modification 1.2 In a separate table 1.2.1 Added by each script that does a modification (INSERT/UPDATE/REPLACE/...) 1.2.2 Maintained by a trigger on each modification 2. On-demand transformation 2.1 Each query has to perform the transformation 2.1.1 Using copy-paste in the source code 2.1.2 Using a library 2.1.3 Using a STORED PROCEDURE 2.2 A view performs the transformation 2.2.1 A separate table replacing the entire table 2.2.2 A separate table just adding the date-fields for the primary keys Am I right to say it's better to recalculate than to store? And would a view be a good solution?

  Read the article

1