Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest

Translate Java to T-SQL

  • 05-05-2006 3: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,466 ✭✭✭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,466 ✭✭✭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