Question about Database Varchar vs Int

09/22/2018 10:47 elitemember21#1
I would like to ask about database here.

Let's just say i've added a datatype in DBManager in the source which is
SQL_PARAM_INPUT, SQL_C_LONG, SQL_VARCHAR

and i wrote a datatype INT in my Character_TBL

Is there gonna be a problem about the saving of data?
09/22/2018 15:49 theo4595#2
VARCHAR can hold number(INT) so its ok. but it's better to parse the data to INT before saving to make sure that it will not save as string.
09/25/2018 12:45 xTwiLightx#3
Quote:
Originally Posted by elitemember21 View Post
I would like to ask about database here.

Let's just say i've added a datatype in DBManager in the source which is
SQL_PARAM_INPUT, SQL_C_LONG, SQL_VARCHAR

and i wrote a datatype INT in my Character_TBL

Is there gonna be a problem about the saving of data?
Of course there will be a problem or at least undefined behaviour can occur.

[Only registered and activated users can see links. Click Here To Register...]
value2 works because SQL Server can interpret parts of the string as a number (which depends on how long that varchar is defined), but as soon as I would define it as 'varchar(4)', it won't work anymore, because it had to parse the 'a', which is not an integer.
Same goes for value3.

As long as your input is just numeric/integer, that could work out well. But you want your application to be consistent, so your types should be consistent too.

So: Better use 'SQL_INTEGER' or 'SQL_BIGINT' for the parameter binding to ensure your data is put into the database as intended.
09/25/2018 14:51 elitemember21#4
Quote:
Originally Posted by xTwiLightx View Post
Of course there will be a problem or at least undefined behaviour can occur.

[Only registered and activated users can see links. Click Here To Register...]
value2 works because SQL Server can interpret parts of the string as a number (which depends on how long that varchar is defined), but as soon as I would define it as 'varchar(4)', it won't work anymore, because it had to parse the 'a', which is not an integer.
Same goes for value3.

As long as your input is just numeric/integer, that could work out well. But you want your application to be consistent, so your types should be consistent too.

So: Better use 'SQL_INTEGER' or 'SQL_BIGINT' for the parameter binding to ensure your data is put into the database as intended.
Thank you very much for this. This helps me understand the database and source more.
09/26/2018 01:37 xTwiLightx#5
Quote:
Originally Posted by elitemember21 View Post
Thank you very much for this. This helps me understand the database and source more.
No problem. This is more a database related topic. :)

Your query could also fail because of the parameter binding itself (which is not the direct execution of statements, but preperation [see Prepared statements] in favor of performance, consistency and - more importantly - security [SQL Injection]). ODBC and other database interfaces can retrieve some errors from the underlying DBMS and redirect that information to the application even before a 'select', 'insert' or something else will be exectuted - which in Flyff's case would be a CQuery-Logfile entry. :P
09/27/2018 12:09 elitemember21#6
Very well said and very informative. Thanks a lot.