To James Bott - Error Using TData

[TimStone]

As an aside, the following code:

Code: Select all

  oCust := TDatabase():New( , "C:\FWH\SAMPLES\CUSTOMER", "DBFCDX", .t. )
   oCust:use()

   if oCust:used()
      oCust:first := Upper( oCust:First )
      oCust:Save()
      XBROWSER oCust
   else
      ? "file not used"
   endif
 

Could be simply:

Code: Select all

  oCust := TDatabase():New( , "C:\FWH\SAMPLES\CUSTOMER", "DBFCDX", .t. )
   IF oCust:use()
      oCust:first := Upper( oCust:First )
      oCust:Save()
      XBROWSER oCust
   else
      ? "file not used"
   endif
 

Now this is actually still more than one needs. You could do a class tCustomer that inherits from tData, and automatically opens the file, sets the index, and is poised to position to the correct record; and the ultimate code would be:

Code: Select all

  oCust := TCustomer():New( nID )
      oCust:first := Upper( oCust:First )
      oCust:Save()

      XBROWSER oCust
 

In this case a new class tCustomer is created. It is called with the nID to position the record, the data is changed, and saved. Of course, since tData holds the field values in buffers they all would want to be written back, and if a field is locked, that woulde be a problem.

The value of tData is that is a class that INHERITS from tDatabase and does many things automatically. Used with tRecord, it is a safe way to edit data easily outside of the saved records, and when the changes are complete and confirmed, it then saves the values back to the actually file. Those of us who use it appreciate the benefits.

[Silvio.Falconi]

Tim,
Nages answred you read the messages above!!!

If Tdata is a class that INHERITS from tDatabase Must work better than Tdatabase

leaving out if you can or can't make a Tcustomer class (that's not the point)

If I can open a dbf with

oCust := TDatabase():New( , "C:\FWH\SAMPLES\CUSTOMER", "DBFCDX", .t. )

it must open also with

oCust := TData():New( , "C:\FWH\SAMPLES\CUSTOMER", "DBFCDX", .t. )

it is clear that Tdata does not read the new DB7 formats

"That is the reason why FIELDPUT() resulted in a runtime error."

I mean of Structure of a standard DBF header
you can found here http://www.dbfree.org/webdocs/1-documen ... ations.htm

>Those of us who use it appreciate the benefits.
then I wish also Know who are the people use tdata

But you realize that we are playing since December with the Tdata and yet I cannot solve my problems, all this is absurd !!!
because someone told me that with tdata I would have solved and I would have immediately converted my application from single user to multiuser instead it was a "cartagine" (a real failure) I am striving to find possible solutions but after 5 months still I am not released with a decent release

[Otto]

Hello Silvio,
I use TData for many years now.

Best regards,
Otto

Code: Select all

class TWelldbf from TData
   DATA cDataBase, lOffert

   METHOD New()

   METHOD Create_dbf()
   
   METHOD saveex()

endclass

//---------------------------------------------------------------------------//

method new( cBuchungsNr )
    ::lOffert    := .f.
   ::cDataBase := setup():Daten + "dataWell\" + cBuchungsNr

   if ! file( ::cDataBase +".dbf" )
       ::Create_dbf()
   endif
   super():new(, ::cDataBase  )

   IF ::use()
      ::SetOrder(1)
      ::gotop()
   ENDIF

return self

//---------------------------------------------------------------------------//

METHOD Create_dbf()
   local aDBF          := {}
   local cdbf          := ::cDataBase
   *----------------------------------------------------------
    
    
   WH_DBcreate_wellnessQuittung( ::cDataBase + ".dbf")
      
   set exclusive on
   use &cDbf new ALIAS re_tmp1

   index on field->zinr + PADL(str(field->zeile),6,"0")   tag re_zeile
   index on field->ZINR + field->ARTNUM + field->BEZEICHNUN        tag re_samm
   index on field->artnum                          tag re_artnum
   index on field->ZiBonNr                         tag rg_ZiBonNr
   index on field->zinr + dtos(field->bondatum)    tag re_zinrdate
   index on field->zinr                            tag re_zinr
   index on field->name                            tag gaston
   index on str(field->zeile,6)                    tag re_N_zeile
   index on field->zinr + field->BEZEICHNUN        tag re_tele
   index on field->konto                           tag re_konto
   use
   set exclusive off

return nil
//------------------------------------------------------------------------------------------//

METHOD saveex()
  ::datum      := date()
  ::bondatum   := date()
  ::Zeit := nTime()
  
  super:save()

return nil

//----------------------------------------------------------------------------//

[Marc Venken]

Maybe the question is for 'NEWER' users of FWH.

Tdatabase (FW) is evolved over the new release since years now
Tdata (James) has been of may still be an enhanced Tdatabase

All Respect for both !!!

But anno 2019 and in cases of NEW projects.... Is Tdata still that much better? (Using Tdata in projects by users that have implemented Tdata will always continue, because the work that is costs .)

I've not seen new releases of Tdata, but i'm not a Tdata user, so maybe there is a Update formula from Mr. James..

It's not my intension of starting a Pro/contra from users, but only a fair point of view for new projects.

[Silvio.Falconi]

Hello Silvio,
I use TData for many years now.

Best regards,
Otto

Maybe you and I are different in proceeding with the structure of a management application

maybe you don't need the procedures that I need or

maybe you never happened to create them

in fact when there was a discussion on the forum of the customer number you answered that you don't use the code for the customer, instead I have to have it and it must be sequential because the law imposes on me the same way the progressive number of invoices.

Let us admit that you use Tdata and your operator cancels the insertion of an invoice, losing the invoice number because in fact, according to James's scheme, if you do not save the invoice, later you have no way to recover that invoice number and you have an invoice number 0001 and then 0003 losing the number 0002

the question is very simple

In Italy the invoices must have progressive numbers ie 1,2,3,4,5 ... because the law says so

Do you NO need progressive number of invoices in Austria?


probably not even in America because both Tim and JAmes have always told me that I was wrong,

that I was insisting on trivial matters and for this I am very sorry,

I don't want to have the risk of re-building twice an application because my customer one day doesn't see the bill number sequentially
is a crazy and unconscious reasoning this ...

"... the tdata class works very well, if then dear silvio you can not make sequential numbers is not our concern ..."

[Otto]

Hello Silvio,
In Austria we have a system that similar to the Italian.

All business cases must be recorded continuously and tamper-proof.

And how will you proof thas you can't maipulate a system you need date and time too.

What you want to do is incompatible with that.


Sincerely
Otto

[Silvio.Falconi]

Hello Silvio,
In Austria we have a system that similar to the Italian.

All business cases must be recorded continuously and tamper-proof.

And how will you proof thas you can't maipulate a system you need date and time too.

What you want to do is incompatible with that.


Sincerely
Otto

Right Invoice number of Data/time

>What you want to do is incompatible with that.

I really don't understand ... what do you mean? what do i want to do?

[TimStone]

Silvio,

For those following, I need to clarify that I would NOT take part in this thread except you keep sending me emails directing me to it and asking for comments. Also, for those unfamiliar with tData, it is a class that INHERITS from tDatabase, NOT A REPLACEMENT, and for those of us who use it correctly, it is very useful.

Since you directed me here, the reality is that I carefully read every post including Nages comments. He believes the problem is with the addition of an autoincremental field, which is read only once the record is established. Thus, when the Save() method is exercised, the data cannot be written from the buffer to that field, causing an error. I will never have this type of error because I create my own unique ID's when I create a customer record, and it is part of my application code. That is of benefit because not only do I add the ID, but also a date time stamp and other important tracking information into other fields.

Since you have a way to do what you want, what is the reason for this post? You have a programming solution, so why continue to revisit tdata when you clearly do not want to use it ?

Again, I really did not intend to comment here, but I keep getting your emails asking me to do so. I have plenty to do right now, so please stop sending them to me.

Tim

[Silvio.Falconi]

Silvio,

For those following, I need to clarify that I would NOT take part in this thread except you keep sending me emails directing me to it and asking for comments. Also, for those unfamiliar with tData, it is a class that INHERITS from tDatabase, NOT A REPLACEMENT, and for those of us who use it correctly, it is very useful.

Since you directed me here, the reality is that I carefully read every post including Nages comments. He believes the problem is with the addition of an autoincremental field, which is read only once the record is established. Thus, when the Save() method is exercised, the data cannot be written from the buffer to that field, causing an error. I will never have this type of error because I create my own unique ID's when I create a customer record, and it is part of my application code. That is of benefit because not only do I add the ID, but also a date time stamp and other important tracking information into other fields.

Since you have a way to do what you want, what is the reason for this post? You have a programming solution, so why continue to revisit tdata when you clearly do not want to use it ?

Again, I really did not intend to comment here, but I keep getting your emails asking me to do so. I have plenty to do right now, so please stop sending them to me.

Tim

>Since you have a way to do what you want, what is the reason for this post?

do you saw the error ?






I too did not want to answer you dear Mr. Tim because I am sure that whatever I say you will reply with so much crap, the very ones you wrote to me in private without solving the problems I have,

Do you know what I think?
I think you haven't compiled the test that I put at the beginning in the first post, you just want to argue that the tdata is a class "INHERITS from Database" but that's not the point ...

you may have done all the programs you want dear sir, earned many dollars but I don't give a damn, in Italy there are some rules of the Italian Government we can't do what we want !!!

By the way I have never seen a post with your source, nor an object class made by you ... so it is better that you return to play with your grandchildren

dear Tim, stay with us, do I have to say that tdata works well to make you happy? ok
Tdata class of James works very well ... it's just me that I don't know how to make progressive numbers as the law tells me

Are you happy mr tim , now ?

[James Bott]

Silvio,

I have fixed TData to handle the autosequencing field type. This was rather new and I didn't even know it existed until a couple of months ago. You are the first to report the problem. It was fixed with one line of code.

You have often mentioned how old TData is. I don't exactly how you date software, or why that is an issue. TDatabase is even older than TData. Both have evolved over the years. TData was first written in 1995 and has been under continuous use since then. Occasionally, when TDatabase is updated it creates a problem with TData. When I hear about a problem I fix it as soon as I can.

TData was designed to handle as much of the repetitive coding as possible. The philosophy was to write each piece of code only once. So, in this case, it handles all scatter and gather routines, record locking, buffering, loading and saving the data all done with multi-user compatiability. It has worked great with every other customer I have had except you Silvio. Your issues are mostly due to your unorthodox methods of doing things that you (or your client) are unwilling to change. I have been programming since before PC's even came out, and you are the first person that wants to show ID's on new record data entry screens (before the record has been added to the database). Well, since I had never even heard of someone doing this, obviously I did not write TData to do it. This is why your conversion is taking way longer than I expected.

Let us admit that you use Tdata and your operator cancels the insertion of an invoice, losing the invoice number because in fact, according to James's scheme, if you do not save the invoice, later you have no way to recover that invoice number and you have an invoice number 0001 and then 0003 losing the number 0002

That is NOT correct. The built-in capabilities don't have an ID number for new record data entry screens because the record does not yet exist. When the new record is saved, it automatically gets a new sequential number. If the user cancels, then there are no orphan numbers unlike your current system.

The question is very simple. In Italy the invoices must have progressive numbers ie 1,2,3,4,5 ... because the law says so

Actually, TData does conform to Italian rules of using sequential numbers. It is your requirement to display the unknown ID on new records that is creating all the problems.

I have not found any Italian regulation requirement to display an ID BEFORE a record was created. That is only a requirement of your client. In the 24 years that TData has been in use, nobody has asked for that. FW's TDatabase does not support that either. No matter which way you go (procedural code, TDatabase, or TData) you are going to have to write code to handle this.

[Silvio.Falconi]

Silvio,

>you are the first person that wants to show ID's on new record data entry screens (before the record has been added to the database).
Any accounting software has the customer's code on the screen: In Italy the code is linked to the account number that is called Mastro (o Gruppo) and then there is the sub-account generally called Credits vs Customers and then the customer number.

Please don't insist on this topic,
we tried you can't do it like Nages did, avoid writing craps,

I can't deliver a program in which customer numbers or invoice numbers are lost if the operator doesn't make the rescue .

If in America it's right for you, continue your story, in Italy it's not possible !!!

That is NOT correct. The built-in capabilities don't have an ID number for new record data entry screens because the record does not yet exist. When the new record is saved, it automatically gets a new sequential number. If the user cancels, then there are no orphan numbers unlike your current system.

Please do not insist that Nages has succeeded in this as well,

if the user does not save, the Nages procedure saves the unsaved numbers in an archive and then calls them to the next entries.

I don't understand why you still don't understand

Actually, TData does conform to Italian rules of using sequential numbers. It is your requirement to display the unknown ID on new records that is creating all the problems.

I have not found any Italian regulation requirement to display an ID BEFORE a record was created. That is only a requirement of your client. In the 24 years that TData has been in use, nobody has asked for that. FW's TDatabase does not support that either. No matter which way you go (procedural code, TDatabase, or TData) you are going to have to write code to handle this.

[/quote]

Still insisting on a logical thing, the customer code as the invoice code must be shown in the entry dialog,

if your software does not do it does not matter ....

There are many programs in Italy do not insist you want me to send you a program of Italian accounting? , the Gestionale 1 of Zucchetti (zucchetti.it), or EasyFact of the Danea (danea.it)


For a sample Easy Fact of Danea.it Danea it is a Firm leader in Italy it build software from many years
I made a red circle to show to you the code of Invoice and code of customer








Please don't insist, do you want another sample ?

I can send you a Software of Zucchetti.it ( gestionale1)

customer manage of Zucchetti





Account movement of Zucchetti




as you can see it's not just a whim of silvio (or my client) who is inventing what he said, it's something that must be there

I do not ask you to view the ID before saving it but to display the ID in the insertion dialog as all major software in Italy does

[TimStone]

Here is a cut from my customer class. There are many more Methods in the class, but this is how a new client is added using one line:

oClients := TClients():New( 1 ): NewClient()

Code: Select all

//---------------------------------------------------------------------------//
//  Call with:    oClients := TClients():New( nOrder )
//--------------------------------------------------------------------------//
    // All Clients table class. Returns a table object
    //  Updated:    6/9/2015 1:21:39 PM

CLASS TClients from TData
   Method New()
   Method NewClient()
ENDCLASS


Method New( nOrder ) CLASS TClients //Data
   ::super():new(,"eclmst")
   if ::use()
        /*
                1 = "eclnum", "acrnum"
                2 = "eclcom", "upper(clicom)"
                3 = "eclbus", "clibus"
                4 = "eclpho", "clipho"
                5 = "clieml", "clieml"
            */
     ::setOrder(nOrder)
     ::gotop()
   endif
Return self

Method NewClient(  ) class tClients //  Add a new client record               Updated  09/22/2014  16:15

    // Declare LOCAL variables
    LOCAL oConfig, nTaxpar, nTaxlab, oCounter, nCliNum
      oClient := self  //

    // Confirm adding a client
    IF MsgYesNo( "Do you wish to add a new client ?" )

        // Obtain the tax rates
      oConfig := tConfig():New( )
        nTaxpar := oConfig:taxpar*100
        nTaxlab := oConfig:taxlab*100
        oConfig:end( )

        // Open the counter file
        oCounter := tCounter():New( )
        // Increment and save the counter
        oCounter:acrnum ++
        nCliNum := oCounter:acrnum
        oCounter:save()
        oCounter:end()

        // Save the number as a string to the client file
        oClient:append()
        oClient:blank()
        oClient:acrnum := SUBSTR( STR( nCLINUM + 100000, 6 ), 2, 5 )
        oClient:clitax := .T.
        oClient:clcuf1 := .T.
        oClient:cliprl := "R"
        oClient:clipri := "R"
        oClient:clitxr := nTaxpar
        oClient:clitxl := nTaxlab
                oClient:clinew := DTOS( DATE( ) ) + " " + TIME()
        oClient:save()
    ENDIF

RETURN self

 

The one line of code, used in appropriate other places of the program, will add a new client record, assign tax rates and purchasing level ( Retail, wholesale, etc ) and also create a date time stamp. These are just some of the fields in the client file, but they are all filled automatically. I can populate the record on a dialog to fill in all of the other data ( name, address, phones, spouse, department, whatever is of use ).

In the dialog, showing the fields is quite easy, referencing them in the same way they are shown in the class.

oClient:save() will then take all of the data from memory and write it to hte permanent record. I do similar things with service items, inventory, accounting, and of course workorders that are used to create invoices ( or estimates, counter sales, technician worksheets, etc ), and also to review service histories for anything that the business works upon.

Other methods have to do with tax systems for clients, utilities to change data in bulk, and so much more.

[Silvio.Falconi]

Here is a cut from my customer class. There are many more Methods in the class, but this is how a new client is added using one line:

oClients := TClients():New( 1 ): NewClient()

Code: Select all

//---------------------------------------------------------------------------//
//  Call with:    oClients := TClients():New( nOrder )
//--------------------------------------------------------------------------//
    // All Clients table class. Returns a table object
    //  Updated:    6/9/2015 1:21:39 PM

CLASS TClients from TData
   Method New()
   Method NewClient()
ENDCLASS


Method New( nOrder ) CLASS TClients //Data
   ::super():new(,"eclmst")
   if ::use()
        /*
                1 = "eclnum", "acrnum"
                2 = "eclcom", "upper(clicom)"
                3 = "eclbus", "clibus"
                4 = "eclpho", "clipho"
                5 = "clieml", "clieml"
            */
     ::setOrder(nOrder)
     ::gotop()
   endif
Return self

Method NewClient(  ) class tClients //  Add a new client record               Updated  09/22/2014  16:15

    // Declare LOCAL variables
    LOCAL oConfig, nTaxpar, nTaxlab, oCounter, nCliNum
      oClient := self  //

    // Confirm adding a client
    IF MsgYesNo( "Do you wish to add a new client ?" )

        // Obtain the tax rates
      oConfig := tConfig():New( )
        nTaxpar := oConfig:taxpar*100
        nTaxlab := oConfig:taxlab*100
        oConfig:end( )

        // Open the counter file
        oCounter := tCounter():New( )
        // Increment and save the counter
        oCounter:acrnum ++
        nCliNum := oCounter:acrnum
        oCounter:save()
        oCounter:end()

        // Save the number as a string to the client file
        oClient:append()
        oClient:blank()
        oClient:acrnum := SUBSTR( STR( nCLINUM + 100000, 6 ), 2, 5 )
        oClient:clitax := .T.
        oClient:clcuf1 := .T.
        oClient:cliprl := "R"
        oClient:clipri := "R"
        oClient:clitxr := nTaxpar
        oClient:clitxl := nTaxlab
                oClient:clinew := DTOS( DATE( ) ) + " " + TIME()
        oClient:save()
    ENDIF

RETURN self

 

The one line of code, used in appropriate other places of the program, will add a new client record, assign tax rates and purchasing level ( Retail, wholesale, etc ) and also create a date time stamp. These are just some of the fields in the client file, but they are all filled automatically. I can populate the record on a dialog to fill in all of the other data ( name, address, phones, spouse, department, whatever is of use ).

In the dialog, showing the fields is quite easy, referencing them in the same way they are shown in the class.

oClient:save() will then take all of the data from memory and write it to hte permanent record. I do similar things with service items, inventory, accounting, and of course workorders that are used to create invoices ( or estimates, counter sales, technician worksheets, etc ), and also to review service histories for anything that the business works upon.

Other methods have to do with tax systems for clients, utilities to change data in bulk, and so much more.

that you wrote is all right ,I don't doubt the capabilities of the tdata class, surely there are benefits

the point is another

James sad me ( and wrote above)

1) that the customer number or the invoice number cannot be displayed in the entry dialog that is when the operator enters a new customer or a new invoice because according to James that number is not yet saved in the archive, and that I'm just acting up because I want the impossible

2) and if the operator does not save the customer or the invoice loses the number, and you can no longer recover

and for him this is logical

Are we joking ?

[James Bott]

James said to me ( and wrote above)

1) that the customer number or the invoice number cannot be displayed in the entry dialog that is when the operator enters a new customer or a new invoice because according to James that number is not yet saved in the archive, and that I'm just acting up because I want the impossible

2) and if the operator does not save the customer or the invoice loses the number, and you can no longer recover

and for him this is logical

I'm sorry Silvio, maybe you are not understanding what I said. There is never a lost number using my stock TData and TRecord classes. They are built differently than what you want. ID's are only assigned when a new record is saved. Thus, there are never any lost IDs and they are in sequential order in the file.

For the sake of others reading this, Silvio's system gets the next ID from the database by adding 1 to the last used ID in the database. Then this number is displayed on the new record data entry screen. A complication arises when another user starts to add a record when the first user hasn't saved theirs yet. So the second user saves theirs first (and it has the same ID as the first user). Now the first user saves and the system checks to see if the ID exists, and it does, so the system then assigns the next available ID. The problem with this system is that the ID may change from what was initially displayed on the data entry screen. Since the originally displayed ID may or may not be the final ID, then what is the point of displaying it? Personally, I would never show the user data that is not real.

Missing IDs
I did give Silvio an alternate. My system keeps track of IDs in a separate file. I told him we could get the next ID and display it on the screen, then if the user cancels it, the ID is abandoned because it is never saved. These are the missing ID's Silvio mentions. This is the only solution I could come up with to met his requirement.

Nages came up with the idea of keeping track of the missing ID's and using them again. Technically that could work, but the physical location of the records in the file would NOT be sequential and this may be an issue with the Italian regulations. And, at any given time there could still be sequential ID's missing due to cancelation IDs that had not be used yet.

I will admit that my system does not work for him. That does not mean that he can't subclass the Load() and Save() methods and replace them with his own code.

Silvio, all the data entry screens you showed look like they contain existing records not new records. Either that or they are new records that have been completely filled out so we can't tell if they are new records. I have yet to see a blank new record screen with an ID on it.

Two Questions
1) Has anyone seen a system that shows an ID on a blank new record data entry screen?
2) Does anyone have any ideas how to solve this?

[Silvio.Falconi]

James said to me ( and wrote above)

1) that the customer number or the invoice number cannot be displayed in the entry dialog that is when the operator enters a new customer or a new invoice because according to James that number is not yet saved in the archive, and that I'm just acting up because I want the impossible

2) and if the operator does not save the customer or the invoice loses the number, and you can no longer recover

and for him this is logical

I'm sorry Silvio, maybe you are not understanding what I said. There is never a lost number using my stock TData and TRecord classes. They are built differently than what you want. ID's are only assigned when a new record is saved. Thus, there are never any lost IDs and they are in sequential order in the file.

For the sake of others reading this, Silvio's system gets the next ID from the database by adding 1 to the last used ID in the database. Then this number is displayed on the new record data entry screen. A complication arises when another user starts to add a record when the first user hasn't saved theirs yet. So the second user saves theirs first (and it has the same ID as the first user). Now the first user saves and the system checks to see if the ID exists, and it does, so the system then assigns the next available ID. The problem with this system is that the ID may change from what was initially displayed on the data entry screen. Since the originally displayed ID may or may not be the final ID, then what is the point of displaying it? Personally, I would never show the user data that is not real.

Missing IDs
I did give Silvio an alternate. My system keeps track of IDs in a separate file. I told him we could get the next ID and display it on the screen, then if the user cancels it, the ID is abandoned because it is never saved. These are the missing ID's Silvio mentions. This is the only solution I could come up with to met his requirement.

Nages came up with the idea of keeping track of the missing ID's and using them again. Technically that could work, but the physical location of the records in the file would NOT be sequential and this may be an issue with the Italian regulations. And, at any given time there could still be sequential ID's missing due to cancelation IDs that had not be used yet.

I will admit that my system does not work for him. That does not mean that he can't subclass the Load() and Save() methods and replace them with his own code.

Silvio, all the data entry screens you showed look like they contain existing records not new records. Either that or they are new records that have been completely filled out so we can't tell if they are new records. I have yet to see a blank new record screen with an ID on it.

Two Questions
1) Has anyone seen a system that shows an ID on a blank new record data entry screen?
2) Does anyone have any ideas how to solve this?

I'm sorry Silvio, maybe you are not understanding what I said. There is never a lost number using my stock TData and TRecord classes. They are built differently than what you want. ID's are only assigned when a new record is saved. Thus, there are never any lost IDs and they are in sequential order in the file.

I am sorry to contradict you but we have already done so many proofs for customers .prg
exact IDs are only assigned when a new record is saved.

Therefore, IDs are lost are in sequential order in the sysfile file, if the operator does not save a client number in the sysfile archive you can no longer find it because in the Tautoincremental class you assign a + 1 to the ID field so if the operator does not save the number 2 will have in the next entry the number 3 (which is sequential to the number 2) but the number 2 that the operator has not saved can no longer be used and therefore you will have a strange list of the type:

0001 Linares
0003 Bot
0006 silvio

but the numbers 0002, 0004,0005 can never be recovered are you forcing me to publish all sources to prove what we're talking about?

For the sake of others reading this, Silvio's system gets the next ID from the database by adding 1 to the last used ID in the database. Then this number is displayed on the new record data entry screen. A complication arises when another user starts to add a record when the first user hasn't saved theirs yet. So the second user saves theirs first (and it has the same ID as the first user). Now the first user saves and the system checks to see if the ID exists, and it does, so the system then assigns the next available ID. The problem with this system is that the ID may change from what was initially displayed on the data entry screen. Since the originally displayed ID may or may not be the final ID, then what is the point of displaying it? Personally, I would never show the user data that is not real.

but can I ask you a serious question?
are you convinced when writing these craps or do you still not want to understand?

Everything you've just written is missing from the test that Nages created, did you see the test done by Nages?

have you seen how it works?

the test is here ----> http://forums.fivetechsupport.com/viewt ... 80#p221386



if the operator does not save a number he does not lose it because in the test that Nages did he goes to save it in an array and then retrieve it for the next entry or operator,

please why not compile the Nages test and try it in a network lan I allready try it on lan network and run good

if Nages can do it with the Tdatabase ... it comes by itself in a logical way that you can do it with theclass tdata ......because you have always said that the tdata is better than the class tdatabase

try the test and then we'll talk about it