Autoincrement field for DBFCDX

[Franklin Demont]

Hello ,

I made some test with autoincrement field :

DBCREATE(cDbfFile , {{"ID","+",10,0}} , "DBFCDX" , .T. )
DBG DbStruct() // gives ID , + , 4 , 0
? FieldLen("ID") // 4 WHY TRUNCATED TO 4 ?????????????????????????

FOR i := 1 TO 10001
DBAPPEND()
NEXT

? Recno() , FIELD->ID // 10001 , 10001

FIELD->ID accepts a number with length 5 , DSTRUCT seems to give a wrong result !!!

What is the real length ??? maybe 10 ?????
How can it be showed ?
Frank Demont

[Enrico Maria Giordano]

Maybe it indicates the number of bytes used for the field? I'm not sure, I never used autoincrement field, sorry.

EMG

[Rick Lipkin]

Frank

I saw your post also in the xHarbour forum and almost mentioned my comments there ... however, auto-increment means one thing in the Sql world and another in the xBase world.

In the Sql world auto-increment is handled by the database and created automatically .. which in my view is inherently dangerous. If an attacker gained access to a Sql table with the primary key being a "counter" ( auto-increment ) all it would take is a simple add() and update() to inject all sorts of mayhem into your tables.

However, since you are creating your auto-increment ( primary key I presume 'UNIQUE' ) by code .. all it would take from an attacker is _ for the last PK and then add 1 to the count and you have the makings of an un-wanted injection into your database.

Perhaps I have missed the intent of your reasoning for the auto-increment ... ?

Thanks
Rick Lipkin

[Enrico Maria Giordano]

Rick,

I really didn't understand your comment...

EMG

[Rick Lipkin]

Enrico

As you know with any RDMS you can create a Primary key as an auto-increment .. for example in MS access:

cSql += "[InvDetailEid] COUNTER NOT NULL, "
..
..
cSQL += "CONSTRAINT PK_INVOICEDETAIL PRIMARY KEY ( InvDetailEid )"

This will create an auto-increment field meaning when you do a oRs:AddNew() you do not have to address the auto-increment field ( InvDetailEid ) by code .. the RDMS automatically assigns the value.

That can be a blessing or a curse ... If you assign a PK as auto-increment it just may make it easier for a hacker to inject records into your Sql table and create all kinds of havoc .. I have seen it happen when I worked for State Gov .. came in one morning and someone had penetrated one of our web-sites and auto injected a few rows with garbage....

Rick Lipkin

[Enrico Maria Giordano]

I don't see how a primary key can facilitate the work of an attacker. If anyone gains access to my database engine then he can do any kind of worst things to my tables.

EMG

[Rick Lipkin]

Enrico

I agree .. if an attacker gets access to your Sql Database .. there is nothing they can not get. .. As far as the primary key .. I have been on the receiving end of cleaning up damage caused by attackers who penetrated a web site when I was working for State Government .. They had injected several rows of garbage into a database table... and I had the distinct pleasure of ferreting out and removing all the injected data.

Since the Web Developer ( not me ) decided to use a PK that was an auto Increment .. all the attacker needed to do is add records to tables ( inject ) and since the PK was auto incremented, there was nothing to stop the creation of new rows. If the PK were code driven .. meaning the PK was created by the developers code .. it would make it more difficult to inject new rows since the attacker ( in this case ) did not have access to all the field names.

However as you mentioned .. if the attacker had gained full access to the Sql Database .. auto-increment or not .. would be irrelevant.

Rick Lipkin

[Enrico Maria Giordano]

Since the Web Developer ( not me ) decided to use a PK that was an auto Increment .. all the attacker needed to do is add records to tables ( inject ) and since the PK was auto incremented, there was nothing to stop the creation of new rows. If the PK were code driven .. meaning the PK was created by the developers code .. it would make it more difficult to inject new rows since the attacker ( in this case ) did not have access to all the field names.

Now I understand. Yes, if the PK were not autoincrement, it would be easier to find the newly added records, without any doubts.

EMG

[Carlos Mora]

First things first: the real problem is that SOMEONE GOT ACCESS TO THE DB. Saying that autoincremental id fields are an issue is like looking at the finger when somebody points with his finger to the stars.
Autoincremental ID is a pretty good thing in SQL world, giving you an unique id and taking the responsability out of the software.
There is nothing like good practices in security and a trustworthy backup policy.

[nageswaragunupudi]

Hello ,

I made some test with autoincrement field :

DBCREATE(cDbfFile , {{"ID","+",10,0}} , "DBFCDX" , .T. )
DBG DbStruct() // gives ID , + , 4 , 0
? FieldLen("ID") // 4 WHY TRUNCATED TO 4 ?????????????????????????

FOR i := 1 TO 10001
DBAPPEND()
NEXT

? Recno() , FIELD->ID // 10001 , 10001

FIELD->ID accepts a number with length 5 , DSTRUCT seems to give a wrong result !!!

What is the real length ??? maybe 10 ?????
How can it be showed ?
Frank Demont

Autoincrement field value is stored as an Unsigned Long Integer in the DBF, which requires 4 bytes of storage. That is the reason why we see 4 as the field length.
The maximum value is nearly 4 billion. Expressed in decimal notation its length is 10.