Advertisement
Help Keep Boards Alive. Support us by going ad free today. See here: https://subscriptions.boards.ie/.
If we do not hit our goal we will be forced to close the site.

Current status: https://keepboardsalive.com/

Annual subs are best for most impact. If you are still undecided on going Ad Free - you can also donate using the Paypal Donate option. All contribution helps. Thank you.
https://www.boards.ie/group/1878-subscribers-forum

Private Group for paid up members of Boards.ie. Join the club.

Translate Java to T-SQL

  • 05-05-2006 03:07PM
    #1
    Registered Users, Registered Users 2 Posts: 604 ✭✭✭


    Howdy,

    This is a validation function that validates a 16 digit number in a similar fashion to the luhn function. Now this version is written in Java which i dont know very well. I need to translate it to T-SQL for a SPROc.

    Can anyone help ?
    void validateChecksum(String s)
    
        {
    
            StringBuffer stringbuffer = new StringBuffer();
            for(int i = 0; i < s.length(); i++)
            {
                if(s.charAt(i) <= '9' && s.charAt(i) >= '0')
                {
                    stringbuffer.append(s.charAt(i));
                }
            }
    
            char ac[] = stringbuffer.toString().toCharArray();
            int j = 0;
            boolean flag = false;
            for(int k = ac.length - 1; k >= 0; k--)
            {
                if(flag)
                {
                    int i1 = (ac[k] - 48) * 2;
                    if(i1 > 9)
                    {
                        j = j + 1 + (i1 - 10);
                    } else
                    {
                        j += i1;
                    }
                    flag = false;
                } else
                {
                    j += ac[k] - 48;
                    flag = true;
                }
            }
    
            int l = j % 10;
            if(l != 0)
            {
                
            } else
            {
                return;
            }
        }
    


    Heres what i have so far but its not working correctly.
    
    
    DECLARE @MotiveCode varchar(20)
    Set @MotiveCode = '0000000000000000'
    
    Declare @CODE varchar(20)
    DECLARE @i int, @j int, @tmp int, @flag varchar(10)
    
    SELECT @i = 0
    Select @j = 0
    SELECT @tmp = 0
    SELECT @flag = 'True'
    
    
    WHILE (@j < LEN(@MotiveCode))
    	BEGIN
    		Select @j=@j+1
    		IF @flag='True'
    			BEGIN
    				Select @tmp=ASCII(substring(@MotiveCode,@j-1,@j)-48)
    				if(@tmp>9)
    					BEGIN
    						Select @i = @i+1+(@tmp - 10)	
    						
    					END
    				ELSE
    					BEGIN
    						Select @i= @i+1
    						
    					
    					END
    				Select @flag = 'False'	
    			END
    		ELSE
    			BEGIN
    				Select @i = @i + substring(@MotiveCode,@j-1,@j)
    				Select @flag = 'True'
    			END
    	
    	END
    
    Select @j % 10 as Result
    


Comments

  • Registered Users, Registered Users 2 Posts: 1,454 ✭✭✭Smoggy


    I will take a look at this in a few hours when I have the time.


  • Registered Users, Registered Users 2 Posts: 604 ✭✭✭Kai


    Anyone got any help for me on this ?


  • Registered Users, Registered Users 2 Posts: 15,443 ✭✭✭✭bonkey


    The only help I can offer at teh moment is to ask why teh code isn't the same!

    For example, in java at one point, you have j+= i1. In your SQL, in the equivalent place, you have @i = @i + 1, which doesn't seem to make sense, 'cause i1 (in the Java code) is equivalent to @tmp in the java code.

    Also, if I'm reading the code correctly, the Java processes the data from right-to-left (decreasing k), but the SQL from left-to-right (increasing j)

    Indeed, this further begs teh question why you don't use the same variable-names etc. Makes comparison far easier.

    Once you get it working, you can always go back and see if theres optimisations you can spot, but first-off my sugegstion would be to match things up as much as possible.

    jc


  • Registered Users, Registered Users 2 Posts: 1,454 ✭✭✭Smoggy


    Thats one thing I did notice when I was coding it, that what you were doing wasnt a line for line translation , the way I was tackling it was to do a literal ( well as close as I could ) line for line translation.


Advertisement