FiveTech Software tech support forums

I have a clienti.dbf with these fields




I open the Dbf with fwh Tdatabase ( no tdata ofJames)



Then created Xbrowse with DATASOURCE oClienti

I insert also





on Function EditClienti( oRec,oBrw )

I wish add a new record and modify the record selected

I need oRec := oClienti:record() or not ?

When I add a new record I wish add a new" Idcliente" but I need to show it on a get ( readonly)

to calc a new Idclienti I made



or I use this function




then I can show the variable cId




Duplicate function


using the Duplicate () function in insertion works well but in the change tells me that the code is already duplicated and therefore does not allow me to make the change as I solve?



or this is all wrong ?

How I must make it ?

wich is the correct procedure ?


Another problem ...When I make the procedure of save I made





but here could be a problem because when I go to save it is possible that some other inline user has saved a customer with the same IDCLIENTI then how can I do to avoid this inconvenience?

I thinked to make



what is the correct procedure?

You can do all of this in 3 lines of code using my TData, TRecord, and TAutoinc classes.

Please James I ask FWH TDATABASE PLEASE

and then tdata is not easy how you sad .....

You certainly can not hide that to make a simple program with a single file there have been many problems and many still have not solved them yet !!

I wanted to show the customer Id ( codice) in the dialog but with tdata it was not possible or you want to impose your type of programming that I do not like.
My customer (to whom I have to make the software) wants to have the customer code on the edit dialog, I do not care if you do not like it.

- with your Tdata it was not possible to show the customer code (I've been playing with your Tdata since November)
- with tdatabase it seems to be possible

You certainly can not hide that to make a simple program with a single file there have been many problems and many still have not solved them yet !!

All these issues are not related to database and record objects. Most of those problems have been programming errors made during your conversion to using objects. In my previous message I did show you how to make a three line program to do what you were doing in a hundred lines. It can't get much simpler than that.

I wanted to show the customer Id ( codice) in the dialog but with tdata it was not possible.

I never said it was not possible with TData (actually it is TRecord that is being used during an edit). It always shows the ID of an existing record, just not for a blank new record that has not yet been added to the database.

I did say you cannot display an ID for a record that does not exist yet. The TRecord class does not assign a number to a new record until it is saved to the database. This is the best way to do this. Also a blank ID is required for the record object to determine if a record is new or not. If it is new, then during a save() it gets appended, otherwise it gets saved to the original record.

Why do you or your client want to generate an ID for a record that has not yet been saved to the database? If you do this, then you either have to deal with missing ID's in your database, and/or you have to add blank records and then delete them. Also you have to write a lot more code, but you can do it this way if you wish.

They can, of course, see the ID immediately after saving the record. If the edit is from a browse, then the ID will be immediately visible in the browse after the save.

Note also that if you were using the autoincrementing fieldtype (+), then a new record will not have an ID until it is saved, so you would not be able to display that ID either.

When customers ask for things that are difficult to provide, first I ask why. Often there is another solution to the why. Or, I tell them the issues involved and that it is going to cost a lot more. They almost always go for the least expensive choice.

Also, since this is a multi-user app, removing deleted records requires exclusive use of the database, which requires, of course, blocking other user's from working in the app while this is done. The way TRecord currently works, you never have to do this.

As I wrote ...my customer want the same dialog if oldest application.
on oldest application i showed the id on dialog also if then the record is not saved.
on oldest app when I insert a new record
i append a record and show his id save the position on a variable
then if the user not save
my procedure go to the record add and the record is delete
what there is hard?

Your old app is a single user app--everything was exclusive use. Now you have to deal with multiple users so you cannot just pack a database whenever you want without consequences. If the client specifically said they want to see the ID of records that have not been created, then I would ask why? And tell them it is going to cost more in a multi-user app and the reasons why--it is going to take more programming and the users are all going to have to get out of the app while housekeeping is done. It doesn't matter which database object you use, you are still going to have the same issues in a multi-user app.

Basically you are saying that you want to do everything the way you have always done it even though it is now a multiuser app. I'm sorry but you can't. Multi-user apps are more complicated.

If you really want to do it your old way, then do this:


Note that you will have missing IDs in the database. And you have to write more a lot more code than the three lines I showed in a previous message. If you have to do this twenty times there is quite a bit more code.

I highly advise against this approach.

Mr. James

May I ask? You have an AutoInc class. Can it not be used to work the way Mr. Silivo wants?

Silvio,

You never told me why your client wants to see the ID of a new record. Why do they need it? Is there another way to do whatever they need it for?

You can always tell them you can do it in a multi-user app, but there will be extra cost and extra inconvenience for the users. Does he still want it?

Nages,

May I ask? You have an AutoInc class. Can it not be used to work the way Mr. Silivo wants?

See the message right before yours. Maybe they crossed during posting.

Yes, it can be done, but there is still the packing issue that would not exist otherwise.

My clients have never complained about not seeing an ID for a new record. I still can't think of any reason for having it except "it has always been that way."

Anyone else want to weigh in on this issue? Do you conceive of this being a big problem?

James Bott wrote:You can do all of this in 3 lines of code using my TData, TRecord, and TAutoinc classes.

Code: Select all | Expand

oCliente := TCliente():New(oClienti) 
oCliente:blank()

[Edit the record]

oCliente:save()

These 3 lines of code work with TDatabase also.

Dear Mr. Silvio

The basic issue is about AutoInc IDs. Basically the programmer has to decide the logic for this.
Available alternatives:

1. Derive the new ID on the basis on RECNO(). This is what is used in your code above. The danger in this approach is that you will have duplicate IDs when DBF is packed.

2. Use AutoInc field feature of DBFCDX. This is always quite safe.

Note: Using any of the above two approaches in a multiuser environment, we do not know what will be the autoinc ID until we save a new record. Therefore, it is not possible to predict and display in advance what will be the final ID that is going to be written in the DBF.

Using this approach, the ID is displayed a "0" or "NEW" and updated with the actual value when the record is saved. This is what the default dialog of TDataRow (FW_Record) does.

3. Use sequences in an external DBF. Oracle does not offer AutoInc fields. Instead SEQUENCES are used. We can simulate a similar feature with DBFs also. This requires additional table and programming and very careful maintenance of DBFs. We maintain the auto-increment serial number in a separate linked DBF. We increment the number in this DBF and use it as the next ID. Using this approach, it is possible to display the ID in advance in the edit dialog and be sure that the same ID will be used when the new record is saved.

The disadvantage of this approach is that there can be gaps in the IDs if some users start editing a new record but abandon saving it. Even with Oracle, both the programmers and users accept the possibility of gaps in the serial numbers.

Mr. James Bott said his TData suite of classes includes own auto-inc feature. I do not know how it works. That is the reason I asked him if his class can provide the feature in the manner you want. His response is not clearly positive.

Please study carefully and decide what do you choose.
Method-1: Not recommended
Method-2: Safe and simple but you can show the ID in advance on the edit screen.
Method-3: You can show the new ID in the edit screen, but the programming, as well as manitenance of DBFs, is complex and any carelessness will disturb the system.

Dear Nages,
I only asked to change the engine of the archives and not to change the whole source.

I entrusted myself to James's Tdata just because some people talked to me well but I did not know all the problems related to them.

At the beginning using xbrowse I had difficulty even to visualize the images, even I would have to use an alias "calias: nomearea" then James made some modifications and also xbrowse worked this because he knows with his Tdata the old wbrowse again.

You must know that the current situation in a simple little program using a single archive must move a series of classes and subclasses that I believe are lost system resources.

I'll give you a practical example.

a TTclient class is linked to Trecord which in turn is linked to the class TTclienti which in turn is linked to the Tautoinc class which in turn is linked to the Tdata class which in turn is linked to the tdatabase class, to me it seems absurd.


As for my source I do not want to change the aesthetics of the input dialog because my client is used to the dialogs of the old application and changing these dialogs I would risk losing my customers to whom I made the software application.


In the old management (dbf share) I created the customer code in this way:

IF lNew

(ODCli) -> (DbSetOrder (1))
(ODCli) -> (DbGoBottom ())
CCLI: = StrZero (Val ((oDCli) -> NumCli) +1.4)
(ODCli) -> (DbGoTo (NREC))
(here the other fields)
ELSE
CCLI: = (oDCli) -> NumCli



The cCli code is displayed in the input dialog even in READONLY mode

Then at the time of the save of record there is the same control which avoids duplication.

ACTIVATE DIALOG oDlt CENTERED
IF lsave
IF lNew
IF (oDCli) -> (DbSeek (cCli))
(ODCli) -> (DbGoBottom ())
CCLI: = StrZero (Val ((oDCli) -> NumCli) +1.4)
ENDIF

(ODCli) -> (DbAppend ())
(ODCli) - NumCli>: = CCLI
(ODCli) -> Priven: = Date ()
ENDIF
IF! Rlock (oDCli)
here the other rescues of the other fields



It seems absurd to me that I can not do it with tdatabase or with tdata.


All this situation seems to me an absurdity because I'm trying since last November to convert my software by adding other new features.


I wanted to find a solution to use my software in multi-user mode and this whole situation exasperated me.


It's been 3 months and I still have not solved anything.


Of course I tried to convert some programs but I left pieces still not working as for example the designer of the beach (spiaggia.dbf) where at the time of saving in the old program in no-share mode I performed a dbzap of the archive and a new rescue.


I'm talking about a multitude of records, the basic configuration is 25X18 or about 450 records. If the user modifies the configuration several times, the archive (using the share mode and the! Deleted () mode is now maximized since it is not possible to make an archive pack.


Then the file beach.dbf is used in all the software because it is the configuration of the positions of the elements of the beach (umbrellas, palm trees, etc.) and then it is used every time the user updates the main dialog so it is used many times and if the archive is very large, the display times are too slow if there are also deleted records.


The end user, that is to say, the person who operates in front of a terminal can not wait for the window to be refreshed to view the beach because the archive has become large due to deletion.


I tried to make all of this understood to James but even today he writes me in a test saying "... I still did not understand what you are doing ..."


In the services procedure I have a list of items that the end user can rent: chairs, loungers and deck chairs

To facilitate the price list I have also created the possibility to create services composed (type bill of materials) ie for example "two beds, a chair + a deck + a bed" a single article and a single price etc. so if you remember I created single services and multiple services in the same services.dbf archive

Formerly in the old software I used a service code for each service (also this with strzero (codser + 1,4)) displayed in the insert dialog, but it was not possible to insert it because James did not like it.

I tried the new form to my client and did not like it because it is not the same videta as the old software: he wants to see the service code.

By removing the code I had and I have difficulty creating the tariffs and now I stopped because I got impatient,
I dropped my arms and I do not find the light on the horizon to get out of this tunnel

>At the beginning using xbrowse I had difficulty even to visualize the images, even I would have to use an alias "calias: nomearea" then James made some modifications and also xbrowse worked this because he knows with his Tdata the old wbrowse again.

I have no idea why you keep referring to "wbrowse." I never mentioned wbrowse. The problems came about because your code is very unorthodox and I have a hard time figuring it out since there are no comments in the code. I have never seen code that adds records before the data is entered. And I have never seen program that copies entire databases into arrays so the records can be edited. I have never seen programs that delete all kinds of records with every use. These things are not common, so it takes me some time to understand what you are doing.

>You must know that the current situation in a simple little program using a single archive must move a series of classes and subclasses that I believe are lost system resources.

>a TTclient class is linked to Trecord which in turn is linked to the class TTclienti which in turn is linked to the Tautoinc class which in turn is linked to the Tdata class which in turn is linked to the tdatabase class, to me it seems absurd.

Well, that is not exactly true. TRecord does not inherit from TTClienti it just works with it or any other database object. How many links would not be "absurd?" What does it matter if they are "absurd" if they work?

Did you know that TDbcombo inherits from TCombobox which inherits from TControl which inherits from TWindow. Most of the FW language is written using objects. Inheritance is a good thing, not something to be avoided.

Inheritance is one of the key concepts of Object Oriented Programming. This allows you to write code only once and use it in many places. This means your overall code is smaller and thus executes faster and uses less memory, and the code you need to write is less. Less code is easier to write and understand. Less code is less chance of bugs. What is not to like?

>It seems absurd to me that I can not do it with tdatabase or with tdata.

It can be done with database objects. Whether you can do it, or are willing, is another issue.

Using all of your old code prevents you from gaining the benefits of using objects. To use all your old code you are going to have to add a lot of code to make it multiuser and you are going to have to add it (and troubleshoot it) everywhere you add, delete, or update records. And wherever you open tables. Using and tracking aliases is a nightmare which only gets worse as your program grows.

With objects, you have to get used to some change, but in the long run it will take way less time than making your old code multi-user.

>Formerly in the old software I used a service code for each service (also this with strzero (codser + 1,4)) displayed in the insert dialog, but it was not possible to insert it because James did not like it.

I never said that--I don't even remember talking about that. I think you jumped to a conclusion based on something else I may have said. Perhaps you are talking about displaying an ID number for a new record data entry screen? We have discussed this, and although it is unorthdox it can be done. However, since it is unorthodox it is not a feature of either TDatabase or TData. You will have to write extra code for each dialog that you want to do this--and you will have to reuse deleted records.

So far there have been no problems with using OOP, other than it is new to you and you don't like it. All of the problems you have had are procedural program errors--not database class bugs. And there isn't anything you can't do with OOP that you can do with procedural code (since it is all written in FiveWin). But the opposite is not true--you can't write procedural code that can do anything the OOP code can do. OOP allows you to write much less code and that means it takes less work and there are less chances for errors. With less code it is much easier to read and to understand, and it excutes faster.

>It's been 3 months and I still have not solved anything.

I guess that depends on how you define "solved anything." You have converted some large sections of code successfully. Why don't you try converting the same section of code without objects and see how that effort compares?

>Of course I tried to convert some programs but I left pieces still not working as for example the designer of the beach (spiaggia.dbf) where at the time of saving in the old program in no-share mode I performed a dbzap of the archive and a new rescue.

This issue has nothing to do with using objects, this has to do with making the app multi-user. You have to solve this problem whether you use objects or not.

>The end user, that is to say, the person who operates in front of a terminal can not wait for the window to be refreshed to view the beach because the archive has become large due to deletion.

Again this is a problem you have to solve now becuase you are making a multi-user app. This is not related to using database objects. And further, I have showed you how you can reuse deleted records (using objects) rather than removing them. Oh, and I'm sorry but you have to add another class to do this.

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them" -Albert Einstein

James Bott wrote:

>At the beginning using xbrowse I had difficulty even to visualize the images, even I would have to use an alias "calias: nomearea" then James made some modifications and also xbrowse worked this because he knows with his Tdata the old wbrowse again.

I have no idea why you keep referring to "wbrowse." I never mentioned wbrowse. The problems came about because your code is very unorthodox and I have a hard time figuring it out since there are no comments in the code. I have never seen code that adds records before the data is entered. And I have never seen program that copies entire databases into arrays so the records can be edited. I have never seen programs that delete all kinds of records with every use. These things are not common, so it takes me some time to understand what you are doing.

>You must know that the current situation in a simple little program using a single archive must move a series of classes and subclasses that I believe are lost system resources.

>a TTclient class is linked to Trecord which in turn is linked to the class TTclienti which in turn is linked to the Tautoinc class which in turn is linked to the Tdata class which in turn is linked to the tdatabase class, to me it seems absurd.

Well, that is not exactly true. TRecord does not inherit from TTClienti it just works with it or any other database object. How many links would not be "absurd?" What does it matter if they are "absurd" if they work?

Did you know that TDbcombo inherits from TCombobox which inherits from TControl which inherits from TWindow. Most of the FW language is written using objects. Inheritance is a good thing, not something to be avoided.

Inheritance is one of the key concepts of Object Oriented Programming. This allows you to write code only once and use it in many places. This means your overall code is smaller and thus executes faster and uses less memory, and the code you need to write is less. Less code is easier to write and understand. Less code is less chance of bugs. What is not to like?

>It seems absurd to me that I can not do it with tdatabase or with tdata.

It can be done with database objects. Whether you can do it, or are willing, is another issue.

Using all of your old code prevents you from gaining the benefits of using objects. To use all your old code you are going to have to add a lot of code to make it multiuser and you are going to have to add it (and troubleshoot it) everywhere you add, delete, or update records. And wherever you open tables. Using and tracking aliases is a nightmare which only gets worse as your program grows.

With objects, you have to get used to some change, but in the long run it will take way less time than making your old code multi-user.

>Formerly in the old software I used a service code for each service (also this with strzero (codser + 1,4)) displayed in the insert dialog, but it was not possible to insert it because James did not like it.

I never said that--I don't even remember talking about that. I think you jumped to a conclusion based on something else I may have said. Perhaps you are talking about displaying an ID number for a new record data entry screen? We have discussed this, and although it is unorthdox it can be done. However, since it is unorthodox it is not a feature of either TDatabase or TData. You will have to write extra code for each dialog that you want to do this--and you will have to reuse deleted records.

So far there have been no problems with using OOP, other than it is new to you and you don't like it. All of the problems you have had are procedural program errors--not database class bugs. And there isn't anything you can't do with OOP that you can do with procedural code (since it is all written in FiveWin). But the opposite is not true--you can't write procedural code that can do anything the OOP code can do. OOP allows you to write much less code and that means it takes less work and there are less chances for errors. With less code it is much easier to read and to understand, and it excutes faster.

>It's been 3 months and I still have not solved anything.

I guess that depends on how you define "solved anything." You have converted some large sections of code successfully. Why don't you try converting the same section of code without objects and see how that effort compares?

>Of course I tried to convert some programs but I left pieces still not working as for example the designer of the beach (spiaggia.dbf) where at the time of saving in the old program in no-share mode I performed a dbzap of the archive and a new rescue.

This issue has nothing to do with using objects, this has to do with making the app multi-user. You have to solve this problem whether you use objects or not.

>The end user, that is to say, the person who operates in front of a terminal can not wait for the window to be refreshed to view the beach because the archive has become large due to deletion.

Again this is a problem you have to solve now becuase you are making a multi-user app. This is not related to using database objects. And further, I have showed you how you can reuse deleted records (using objects) rather than removing them. Oh, and I'm sorry but you have to add another class to do this.

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them" -Albert Einstein

( only for the first point) this is not true, initially she told me that tdata works very well with the listbox (wbrowse), in fact if you remember we had to put a SetoDBF (odbf) or a calias because the tdata did not work, I sent the sources with notes explanatory notes for each group of operations and all the procedures that had to be done