With your code, Black Rose, it will appear to work correctly to users while in reality it is not.
It is storing the data in nVault with a single character as the key because it is using the right-most byte in the cell as the ascii character since it is expecting a string (which is normal for how Pawn stores/interprets strings).
PHP Code:
public client_authorized( id )
{
//Lets pretend my SteamID 'value' is 2298457
giSteamID[ id ][ 0 ] = 2298457 //GetUseriSteamID( id );
gPoints[ id ] = nvault_get( g_Vault , giSteamID[ id ] )
//Print the key as both an integer as string.
server_print( "nvault_get : [%d] [%s]" , giSteamID[ id ] , giSteamID[ id ] );
}
Output
Code:
nvault_get : [2298457] [Y]
steam id integer = 2298457
char 'Y' ascii val = 89
In binary:
2298457 = 0000 0000 0010 0011 0001 0010
0101 1001
0000089 = 0000 0000 0000 0000 0000 0000
0101 1001
So when passing a cell holding 2298457, Pawn is taking the right-most byte value of 89 and say's oh ok, this means character 'Y' is the key.
I know you already acknowledged this issue, but for anyone that may have tried your code and saw it working, I wanted to explain it more because it should not be used.
Even with SQL, wouldn't you still need to convert it to a string in your SQL query? I think this would be useful in some type of hash lookup table where it takes an integer value as the input.
__________________