To James Bott - Error Using TData

[Silvio.Falconi]

James,

all snapshot I insert above are contain new records
if you wish I can send you an application or give you link to dowload demo Italian program
some links

EasyFact - danea.it Link to download https://www.danea.it/service/download/download.asp?ID=demo-ef09

GenioSoft Maestro link http://www.geniosoft.net/maestro?gclid=Cj0KCQjwuLPnBRDjARIsACDzGL2BOq7xMowt1IZzjuxMZt6-KgjWeAaifNhcpMwwaZ6yCyfLh2e2EVgaAp0DEALw_wcB#scrollMaestro

Idea software MonAmi 300 work on Sql link

Customer New


New invoice


But because you insist with this absurdity, it is from December that you insist,

but I was wrong I didn't have to tell you that I had a job deadline, I made it wrong

[James Bott]

Silvio,

There are four scenarios we have identified:

1) Do it like most systems do, assign the ID after the new record is saved. Every system I have ever seen uses this method and thus TData was written to work this way.

2) Do like your friend Alfredo does, and use a fake ID on the new record data entry screen. Then aissgn the real ID when saving the new record.

3) Use Nages' system that recovers abandoned IDs and uses them later. This leaves the database with IDs out of physical order, Also, there can be some missing ID's at any given time (did you realize this?).

4) Use my alternate system that shows the real ID on a new data entry screen and just abandons IDs that are created by the user cancelling a new record entry screen. I suggested this BEFORE I knew about your Italian regulations.

Number 1 meets your Italian regulations as near as I can tell.

Number 2 probably meets the regulations too. Users will likely be very confused why the ID on the new record data entry screen isn't always the ID in the record.

Number 3 and 4 probably don't meet the regulations due to lack of sequential IDs in the physical order (not indexed) of the database. Also I believe you have to store the date and time in each record and these would be out of order when you reused abandoned IDs.

Silvio, you have to pick which one you want to use. If you pick something other the number 1 above, then you are going have to write the code for it.

I sold you a product that works very well as is. If you want it to work some other way, that is up to you and you will have to write new code for that. I did not claim that my product would do everything and anything you wanted.

What I would suggest is you go with Number 1 (no new coding involved) for now. You can tell your client that showing the ID on the new screen is an unsolved issue right now, and you don't want to hold up the entire project over it. Later, you can go back and work on it. Meeting the regulations are "must have", displaying the ID on the new record screen is a "nice to have."

Since you will probably only have to write new Load() and Save() methods for the database class to change the behavior of the app, all the data entry screens will automatically inherit the new behavior. This is one of the great things about using objects. If you are not convinced that this will work, I will write up 2 (very simple) different systems as a demo to prove it.

So don't hold up the whole project over how to display the ID on a new record data entry screen.

[nageswaragunupudi]

Mr. James

Very clear and I agree.

[James Bott]

Silvio,

Regarding your screenshots of new record data entry screens with IDs, have you tried to figure out what happens if you cancel. Can you cancel one, then add another and see if the second one gets the ID of the cancelled one, a new ID, or?

Are you aware of the concept of voiding? The record is left intact but marked "void" and it is never deleted. This is common practice with accounting software here. I wonder if new records that are canceled are saved in the file and just voided? Maybe you could try this on your demo.

[Silvio.Falconi]

Silvio,

Regarding your screenshots of new record data entry screens with IDs, have you tried to figure out what happens if you cancel. Can you cancel one, then add another and see if the second one gets the ID of the cancelled one, a new ID, or?

Are you aware of the concept of voiding? The record is left intact but marked "void" and it is never deleted. This is common practice with accounting software here. I wonder if new records that are canceled are saved in the file and just voided? Maybe you could try this on your demo.

James, I really didn't understand where you want to end ...

For many years I have used the program of Alfredo Arteaga "Cawind" and "RCWind".

Obviously adapting it to my needs.

It is a multiuser system and therefore function in a LAN network.

Years ago I created a software for a library with many network stations, using Alfredo's own sources

In the new version it even uses Advantage Table having the same dbf files
you can go and download yourself from the site despachoarteaga.com.mx

In the entries the customer number is visible as the invoice number is visible, I also showed you the source code but you still say that you can't do with tdata / tdatabase.

Even Angel Canudas in his Eurogest software uses the same technique and uses the Tdatabase class

The Italian software that I listed to you do the same thing
this morning I tried to do what you asked me




this morning I tried to do what you asked me

I used the software Idea program
I entered a new customer (the code is visible on the screen) on a PC
I put a new customer on another computer
then I canceled the insertion on the first one and also on the second pc
I went to check the client archive from dos and saw that there is no record in the archive

then I open new the software and add new record and th enumber is that I try to add before...

[Silvio.Falconi]

for proposal number (4)

I not remember you sad this.... you allways sad it is not possibile

then I not understood what you mean

when I add a new customer ( or a new invoice ) the number is on dialog ?

then I think you not undestood the rule of Italian Goverment

the Italian regulation does not allow for canceled or canceled numbers:

- for the customer / supplier registry, only the number is sufficient (but it must be progressive)
- for articles ,there is the article code so there is no problem
- for invoices, ( alsoaccounting movements, loading, unloading and reversal in the warehouse, first accounting note) the numbers are linked to the example date n.1 invoice of the 08/25/2019
- the fiscal receipts, ie those of cash registers or receipts, are like invoices but must be connected to the example time example n.1 invoice of the 08/25/2010 Time 23.45

[Silvio.Falconi]

that is, what I want James to understand is this:

the error is right in the Tautoincremental class

when entering a new customer, the append () method of Tautoincremental is called

if oSys: found () // if .t. DBF filename was found in the system file
nID: = oSys: id + 1 // increment the key field value by 1


if the saving is canceled by the user there must be another method which cancels the counter, ie it opens the sysfile file and saves

nId: = oSys: = id-1// decrement the key field value by 1

when a user add a new customer have the real number ( no lose any numbers)

is it possible to make it ?

only this way your system could work

[Silvio.Falconi]

It is right that I will be able to see the last number, that is, only after the rescue, I agree very much

but the question comes spontaneously

if the operator cancels the entry and the Id on sysfile.dbf increases by +1

I will then have an illegal list of invoices with non-progressive numbers

is this normal?
for me it's a crazy shit

[Silvio.Falconi]

James, Nages according to YOU


I sad to my customer "the ID displayed is not reliable and could be changed when the cust record is saved."

because I don't have to lose the number if the progressive number I deduce from the last of the same table +1

without using sysdbf.file and autoincremental class

sample:

at init

IF nMode == 1 .or. nMode == 3 // add new or duplicate
oCust: gobottom ()
CCLI: = StrZero (Val (oCust: NumCli) +1.4)

else
cCli: = oRec: numcli // modify
endif

dialog
@ 12, 5 SAY "Code:" OF oDlg SIZE 19, 8 PIXEL
@ 10, 36 GET aGet [1] VAR cCli OF oDlg SIZE 25, 10 PIXEL READONLY





before to save
If nMode == 1 .or. nMode == 3 // add new or duplicate
If oCust: seek (cCli)
oCust: gobottom ()
CCLI: = StrZero (Val (oCust: NumCli) +1.4)
endif
endif

Oreč: NumCli: = CCLI
Oreč: save ()

in this way I should not lose any number if I cancel the save
if instead I use an external file I lost the number

[James Bott]

Silvio,

this morning I tried to do what you asked me

I used the software Idea program
I entered a new customer (the code is visible on the screen) on a PC
I put a new customer on another computer
then I canceled the insertion on the first one and also on the second pc
I went to check the client archive from dos and saw that there is no record in the archive

then I open new the software and add new record and th enumber is that I try to add before..

We need to know the IDs. Do this and record all the IDs.

1) User 1: Start new entry screen and record the ID

2) User 2: Start new entry screen and record the ID. Then save the record and look for the saved record in a browse if possible. If found then record the ID.
3) User 1: Save the new entry screen. Note if you get a message with a changed ID and if so, record the ID, otherwise look in the file if you can and find the ID and record it.

We need to try to figure out how they are handling IDs.

[James Bott]

Silvio,

that is, what I want James to understand is this:

the error is right in the Tautoincremental class

when entering a new customer, the append () method of Tautoincremental is called

if oSys: found () // if .t. DBF filename was found in the system file
nID: = oSys: id + 1 // increment the key field value by 1

if the saving is canceled by the user there must be another method which cancels the counter, ie it opens the sysfile file and saves

nId: = oSys: = id-1// decrement the key field value by 1

when a user add a new customer have the real number ( no lose any numbers)

is it possible to make it ?

First to be clear, there is no error in the TAutoincrement class. It works as designed without error.


Your concept is possible to make, but it won't work.

User 1 opens a new record screen with an ID of 10
User 2 opens a new record screen with an ID of 11
User 2 saves the record with an ID of 11
User 1 cancels and the ID counter is decremented from 10 to 9
User 2 starts a new record and gets an ID of 9
User 2 saves the record. Now there are two records with an ID of 9

Now you have duplicated IDs in the file.

[TimStone]

I would like to divert to share some general thoughts.

1). I often see situations where my client will start something on one computer, walk away, and others will use the same process on their computers ( with different data ). When user A goes to add a customer, the number is assigned to the new/blank appended record and the counter advanced. The next person ( could be a fraction of a second later ), gets the next number. With this being done thousands of times a day by my clients, we never have an issue with duplicate account numbers so I know it is safe. All of this discussion is about customer ID numbers, and unfortunately I still do not understand why any government would care about the ID number ( used for linking a customer to other data ) assigned, and insisting they be in sequential number plus date time order. ( I'm not being argumentative. I just don't understand that point with customer ID numbers. )

2). I do understand the importance of invoice numbers being sequential in number and date/time.. In my country, when the government does a tax audit of a company, they want to see every invoice. If any numbers are missing, they assume they have been hidden, so they assign the average value of all invoices to each missing one, determine the tax that should have been paid, and then collect that plus fines. This is a big penalty so we want to avoid it. My program creates workorders, and the customers, serviced unit, parts, labor, recommendations, and more are all linked to it. When a new workorder is started, it is assigned the next sequential number, and date/time stamped. My clients use that to provide an ESTIMATE to the client. If the work is declined, a statement is added to the workorder, and the customer signs it saying nothing was performed. If they agree to have the work performed, all of the sales data is added, and it is printed as a final invoice. We've done it this way for over 35 years and no business has ever had a problem in an audit as a result. The government representative can clearly see every single completed, or rejected, job and there is never a gap in the invoices causing suspicion.

3). One of the things I learned in the very beginning of my programming business ( 1982 ) is that listening to the client is very important. However, it is also vital to walk them through a process of understanding what they really want. Many studies have shown that people hire programmers, share what they think they want, and when it is presented, it doesn't fit their needs at all. We need to focus on the ultimate goal, and provide that solution in a way that is easy for them to use. It is important, when a client wants something, to have them explain WHY it is important. Often this may lead to other solutions instead of what they think it should be.

[Silvio.Falconi]

James read last message..where I wrote without sysdbf file
Because the probkem is ......reading extern file

[James Bott]

Silvio,

I sad to my customer "the ID displayed is not reliable and could be changed when the cust record is saved."

because I don't have to lose the number if the progressive number I deduce from the last of the same table +1

without using sysdbf.file and autoincremental class

sample:

at init

IF nMode == 1 .or. nMode == 3 // add new or duplicate
oCust: gobottom ()
CCLI: = StrZero (Val (oCust: NumCli) +1.4)

else
cCli: = oRec: numcli // modify
endif

dialog
@ 12, 5 SAY "Code:" OF oDlg SIZE 19, 8 PIXEL
@ 10, 36 GET aGet [1] VAR cCli OF oDlg SIZE 25, 10 PIXEL READONLY

before to save
If nMode == 1 .or. nMode == 3 // add new or duplicate
If oCust: seek (cCli)
oCust: gobottom ()
CCLI: = StrZero (Val (oCust: NumCli) +1.4)
endif
endif

Oreč: NumCli: = CCLI
Oreč: save ()

in this way I should not lose any number if I cancel the save
if instead I use an external file I lost the number

If you want to do it that way then just write a subclass of TData to do it.

There are two issues:

1) You are lying to the user when you show an ID that may be wrong. This can create all kinds of confusion. If users are relying on it to be valid, then it is changed, when they look it up, it will be a different item, invoice, or whatever.

2) If you use it with files that can have deleted records, then you can get duplicate IDs. For example, in the item file you have an item with ID 10. You add that to an invoice, then later you delete that item and add a new item. Now you print the invoice and it will have the new item on it, not the old one that you originally added. This will be a bug that is very hard to figure out later. This is not a problem when using a separate file to track IDs.

[Silvio.Falconi]

James,
I found an agreement with the customer the customer number is not true until it is saved ok?
then,

what you wrote to me is not possible because on my application you cannot delete customers if they have invoices or procedures related to that customer number