Page 1 of 2
New field type ?
Posted: Fri Oct 26, 2018 8:51 am
by 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
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)
Re: New field type ?
Posted: Fri Oct 26, 2018 9:12 am
by 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
Re: New field type ?
Posted: Fri Oct 26, 2018 3:16 pm
by 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
Re: New field type ?
Posted: Sun Oct 28, 2018 12:52 am
by 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?
Re: New field type ?
Posted: Sun Oct 28, 2018 7:04 am
by 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
Re: New field type ?
Posted: Sun Oct 28, 2018 10:06 am
by Enrico Maria Giordano
Lailton wrote: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
Re: New field type ?
Posted: Sun Oct 28, 2018 10:06 am
by Enrico Maria Giordano
James Bott wrote: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
Re: New field type ?
Posted: Sun Oct 28, 2018 4:02 pm
by 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
#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.
Re: New field type ?
Posted: Sun Oct 28, 2018 4:50 pm
by Enrico Maria Giordano
Good to know!
EMG
Re: New field type ?
Posted: Mon Oct 29, 2018 11:56 am
by Lailton
Hi Nages,
So I dont see problem at all, right?
I have plan to take look to it on the next days.
Thanks
Re: New field type ?
Posted: Mon Oct 29, 2018 2:49 pm
by 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
Re: New field type ?
Posted: Mon Oct 29, 2018 3:18 pm
by nageswaragunupudi
Lailton wrote: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.
Re: New field type ?
Posted: Mon Oct 29, 2018 3:34 pm
by 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.
Re: New field type ?
Posted: Mon Oct 29, 2018 4:07 pm
by 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
Re: New field type ?
Posted: Thu Nov 01, 2018 11:34 am
by 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