New field type ?

[Silvio.Falconi]

I saw on strcture customer there is +

local aFields := { { "ID", "+", 4, 0 },;
{ "FIRST", "C", 20, 0 },;
{ "LAST", "C", 20, 0 },;
{ "STREET", "C", 30, 0 },;
{ "CITY", "C", 30, 0 },;
{ "STATE", "C", 2, 0 },;
{ "ZIP", "C", 10, 0 },;
{ "HIREDATE", "D", 8, 0 },;
{ "MARRIED", "L", 1, 0 },;
{ "AGE", "N", 2, 0 },;
{ "SALARY", "N", 9, 2 },;
{ "NOTES", "C", 70, 0 } }

where did this type of non-standard file come out now if the dbf is an old format?

what other types exist?

there is an error in fwdbu when I try to change the field type to the ID field

Code: Select all  Expand view  RUN

Application
===========
   Path and name: C:\Work\Bin\fivedbu.exe (32 bits)
   Size: 6,458,880 bytes
   Compiler version: Harbour 3.2.0dev (r1803161710)
   FiveWin  version: FWH 18.02
   C compiler version: Borland/Embarcadero C++ 7.0 (32-bit)
   Windows version: 6.1, Build 7601 Service Pack 1

   Time from start: 0 hours 0 mins 44 secs
   Error occurred at: 26/10/2018, 10:54:26
   Error description: Error BASE/1132  Bound error: array access
   Args:
     [   1] = A   { ... } length: 5
     [   2] = N   0

Stack Calls
===========
   Called from: fivedbu.prg => (b)NEW( 2209 )
   Called from: fivedbu.prg => (b)NEW( 2280 )
   Called from: .\source\classes\WINDOW.PRG => TWINDOW:LDBLCLICK( 2009 )
   Called from: .\source\classes\CONTROL.PRG => TCONTROL:LDBLCLICK( 1744 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:LDBLCLICK( 4789 )
   Called from:  => TWINDOW:HANDLEEVENT( 0 )
   Called from: .\source\classes\CONTROL.PRG => TCONTROL:HANDLEEVENT( 1731 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:HANDLEEVENT( 10514 )
   Called from: .\source\classes\WINDOW.PRG => _FWH( 3368 )
   Called from:  => DIALOGBOXINDIRECT( 0 )
   Called from: .\source\classes\DIALOG.PRG => TDIALOG:ACTIVATE( 298 )
   Called from: fivedbu.prg => NEW( 2307 )
   Called from: fivedbu.prg => (b)BUILDSTRUCTBAR( 2068 )
   Called from: .\source\classes\BTNBMP.PRG => TBTNBMP:CLICK( 693 )
   Called from: .\source\classes\BTNBMP.PRG => TBTNBMP:LBUTTONUP( 944 )
   Called from: .\source\classes\CONTROL.PRG => TCONTROL:HANDLEEVENT( 1721 )
   Called from: .\source\classes\BTNBMP.PRG => TBTNBMP:HANDLEEVENT( 1909 )
   Called from: .\source\classes\WINDOW.PRG => _FWH( 3368 )
   Called from:  => DIALOGBOXINDIRECT( 0 )

there is also another error when I try to save a record ( it not Know the new field type)

[jose_murugosa]

Silvio,

This are the Harbour extended Field Types

Type Short - Code Name - Width (Bytes) - Description
---- ------- ----------------- -------------------------------------------------------------------
D Date 3, 4 or 8 Date
M Memo 4 or 8 Memo
+ AutoInc 4 Auto increment
= ModTime 8 Last modified date & time of this record
^ RowVers 8 Row version number; modification count of this record
@ DayTime 8 Date & Time
I Integer 1, 2, 3, 4 or 8 Signed Integer ( Width : )" },;
T Time 4 or 8 Only time (if width is 4 ) or Date & Time (if width is 8 ) (?)
V Variant 3, 4, 6 or more Variable type Field
Y Currency 8 64 bit integer with implied 4 decimal
B Double 8 Floating point / 64 bit binary

I hope it may help

[James Bott]

Silvio,

I recommend that you not use the + type (auto incrementing) due to some issues. One problem is that you can't reuse deleted records (because the auto-incrementing field cannot be changed). Do a forum search for "auto incrementing" for more information.

James

[Lailton]

Hi James,

What is exactly the problem with this extended type.
This week I was reading about this and I was thinking in use DBF with this + type.

Auto-Incrementing is normal that can not be changed.

Another feature that I am thinking is about the PASSWORD to protected the dbf.

Do you think that is a bad idea to use it?

[James Bott]

As I mentioned, if you use it you cannot reuse deleted records because the autoincrementing field cannot be changed.

Also, if you need to change the file format, you can't just export it, change the database structure, then import that data again because the new empty file is going to auto-increment. If you can't ever delete records, then this might work, but if you can, then you will have issues because as soon as you come to the first deleted record during an import, all records after that will not have the same ID as they did.

I don't know if you can delete records and then pack the file. I assume you can do this, but maybe you can't. I have not looked into all this, but it all sounds like a big headache to me.

I have my own auto-incrementing system that doesn't have the above issues. I can reuse deleted records, so there is never any packing required (and thus no file-locks either).

James

[Enrico Maria Giordano]

Another feature that I am thinking is about the PASSWORD to protected the dbf.

Do you think that is a bad idea to use it?

Unfortunately, you can't password protect DBFs with memo fields.

EMG

[Enrico Maria Giordano]

Also, if you need to change the file format, you can't just export it, change the database structure, then import that data again because the new empty file is going to auto-increment. If you can't ever delete records, then this might work, but if you can, then you will have issues because as soon as you come to the first deleted record during an import, all records after that will not have the same ID as they did.

I don't know if you can delete records and then pack the file. I assume you can do this, but maybe you can't. I have not looked into all this, but it all sounds like a big headache to me.

I agree.

EMG

[nageswaragunupudi]

Mr. James

I beg to disagree on some important observations. Hope you don't mind.

Also, if you need to change the file format, you can't just export it, change the database structure, then import that data again because the new empty file is going to auto-increment. If you can't ever delete records, then this might work, but if you can, then you will have issues because as soon as you come to the first deleted record during an import, all records after that will not have the same ID as they did.

Here is a test program:

Code: Select all  Expand view  RUN

#include "fivewin.ch"

REQUEST DBFCDX

function Main()

   local aStruct  := { { "ID", "+", 4, 0 }, { "TXT", "C", 10, 0 }}

   SET DATE ITALIAN
   SET CENTURY ON
   RDDSETDEFAULT( "DBFCDX" )
   SET DELETED ON

   DBCREATE( "TESTAI", aStruct, "DBFCDX", .T., "TST" )
   FW_ArrayToDBF( { { "ONE" }, { "TWO" }, { "THREE" } }, "TXT" )
   XBROWSER "TST"

   GOTO 2
   DELETE
   GO TOP
   XBROWSER "TST"

   COPY TO "TESTAI2"
   XBROWSER "TESTAI2.DBF"

   // Restructuring
   aStruct  := DBSTRUCT()
   AAdd( aStruct, { "UPDT", "=", 8, 0 } )
   CLOSE TST
   DBCREATE( "TESTAI", aStruct, "DBFCDX", .T., "TST" )
   APPEND FROM TESTAI2
   XBROWSER "TST"

return nil
 

I don't know if you can delete records and then pack the file. I assume you can do this, but maybe you can't.

We can delete records and then pack the dbf.

I use autoinc feature extensively and I am quite comfortable and find the feature very useful. At the same time, I agree this is a matter of personal taste and comfort.

[Enrico Maria Giordano]

Good to know!

EMG

[Lailton]

Hi Nages,

So I dont see problem at all, right?

I have plan to take look to it on the next days.

Thanks

[James Bott]

Nages,

Thanks for pointing that out.

Since you can't do a single APPEND without auto-generating a new ID, I didn't think APPEND FROM would not generate IDs. Now I wonder if you could APPEND FROM duplicate IDs into an existing database, or IDs out of sync.

You still can't reuse deleted records, though.

I do agree that auto-incrementing ID's is very useful, in fact indispensable, and I have always used my own system of doing this. And since I can replace the ID field, I can reuse deleted records, thus no PACKing is needed.

James

[nageswaragunupudi]

Hi Nages,

So I dont see problem at all, right?

I have plan to take look to it on the next days.

Thanks

I never faced any problem. We need to treat this field as ReadOnly field. XBrowse, TDataRow, TDataBase automatically treat the field as readonly and do not allow modification of this field.

Limitations when compared with Sql databases implementing auto increment columns:
It is possible to temporarily disable auto-inc feature and we can directly write unique values to the field and again enable the auto-inc feature. This is very convenient in some situations.
I do not think (not sure) that this facility is available with our RDDs.

[nageswaragunupudi]

Now I wonder if you could APPEND FROM duplicate IDs into an existing database, or IDs out of sync.

Not possible. These RDDs are very reliable.

You still can't reuse deleted records, though.

I do agree that auto-incrementing ID's is very useful, in fact indispensable, and I have always used my own system of doing this. And since I can replace the ID field, I can reuse deleted records, thus no PACKing is needed.

True.
Personally, I do not see it as a big problem or a cause of concern.
Again this is a matter of personal preference.

These are my personal views:
1) We can leave the deleted records as they are.
2) Packing becomes necessary only when there are too many deleted records in the dbf degrading the performance. Then once in a while, we can pack but this need not be a regular necessity.
3) Most important: In a commercial application, it is not a safe practice to allow deletion or modification of a transaction already inserted in a database. Any changes should be made by new rectification entries only. In such highly desciplined software this becomes a non-issue.

[James Bott]

Nages,

I am not trying to convince anyone not to use the auto-inc feature, I was only pointing issues or potential issues. I may take another look at it myself, since you have pointed out that you can APPEND FROM without getting automatic incrementing. That was a show-stopper for me before I knew how it worked.

James

[Admpss]

hi, this new type like autoincrement, work in network environment? can 2 users append an record at same time and autoincrement is ok?
it is compatible with autoincrement from ads files?

thanks