FiveTech Support Forums

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.

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.

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?

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

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

Code (fw): Select all Collapse

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

[Edit the record]

oCliente:save()

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.

>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.

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

>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.

>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.

>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.

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