Major Problems

[Scott Emerick]

Hi All,

I have a very strange thing happening here and I will try to stay calm as I explain it since its been a project I have been working on for months now.

I have a form built on a set that has 1:1 child and grandchild tables.

It seems that when I enter a new record all is well. When I go to change a field value the change is not accepted and reverts back to the original value.

There are no event scripts on the form or fields. There are no field rules. The fields are user entered.

Now here is the strange part. While trying to isolate my problem I created a default form. The new form allowed me to make the changes. I then went back to the old form and it allowed me to make changes. I then tried to compact the database and it showed that one of the child tables was opened. There is nothing on the forms that would have kept the table opened. I then close Alpha and reopen it. Both forms now will not allow the changes but I can do a compact without a open table error.

I hope and pray someone has a simple fix for this and does not tell me the data base is corrupt. There will be many many many hours wasted if I have to recreate from scratch.

PLEASE HELP!!!

Thanks ..

Scott

[mronck]

RE: Major Problems

Hi Scott,

Did you check your referential integrity settings in the set where the forms are based on ?

My first thought would be that something might be corrupted here. It could be something in the process or something in the forms or tables.
To narrow down sources of trouble, maybe the first thing to do is not only shut down the app, but also shut down Alpha and even reset the computer.
Try again.
I also experienced open tables at various moments when trying to compact. Didn't mean anything in my case, always disappeared when the computer was restarted. Only shutting down Alpha not always helped, reason for me to believe something corrupted the memory of the computer.

Oh and Scott......... yes indeed, backups !
(sorry couldn't resist. I am backing up constantly here as afraid as I am to loose that much work).

Succes.

Marcel

[Scott Emerick]

RE: Major Problems

Marcel,

Thanks for the response.

The problem is definatly with the set, I just don't know what or why. I do have backups, however, I just noticed this problem now, 5 backups later.

My set is structured this way.

PARENT
|
|----------- CHILD 1:1 link on JID
| |-------
GRANDCHILD 1:1 link on OID
| |-------
GRANDCHILD 1:1 link on OID
|
|----------- CHILD 1:1 link on JID
|----------- CHILD 1:1 link on JID

Nothing seems out of order to me, yet once the Grandchild tables are added things go crazy.

Scott

[JohnZaleski]

RE: Major Problems

I seen some behavior that leads me to believe there may be some corruption in the index files of the child or grandchild files. Don't just do a rebuild indexe. Delete them and manually re-enter the index tags.
I use code to do this like:
tbq.index_create_begin("POL_TRX","POL_TRX")
index_add("Xposting","POL_TRX + FPT_TYPE")
index1 = tbq.index_create_end()

Good luck

[Scott Emerick]

RE: Major Problems

John,

Thanks for the advise.

I have found the problem and it wasn't with the indexes. It was with the field rules of one of the grandchild tables.

I had several calculated fields of which my calc expression transformed and mutated into something seriously wild. Once I deleted the expressions and made the fields user entered my problem went away.

I have no idea what happened or why, but that problem is solved and I will figure out a work around to get my calcs.

Thank you all

Scott

[crimmelcp]

RE: Major Problems

Scott:
I have seen this sometimes if you insert a firld in the middle of a table instead of at the end.

charlie crimmel

[mronck]

RE: Major Problems

Hi Guys,

I have experienced this kind of errors as well, I mean errors that occur not because of a program bug, but because of us programming things that can not work.

That is an issue with Alpha.
It is that simple to work with, that it invites you to program 'out of the hip'. Create it, test it and see if it works. We all know that such an approach can create huge problems in complex programs. And in the end that is were we all end up: leaving the simple and program rather complex applications with our Alpha stuff.

Developping does not mean fast-typing-code.
It means planning and structurizing on forehand.

Does anybody remember the system flow chart ?
Don't get me wrong: I am making these mistakes as much as anybody else I am afraid.
It should get more of our attention though.

Why not do the math on paper first and really think things over before hitting the buttons ?

Greetings,

Marcel

[JerryBrightbill]

RE: Major Problems

Marcel

Excellent point. Many of us starting by building simple structures for simple needs and then starting adding little additions. The result is like a building with added rooms of many contrasting architectures. The plumbing is a mess, the wiring is a jumble of wires, and there are doors that now go nowhere. But it still works, somewhat.

Many developers still use this method to build a complex structure. It redefines the term "complex". In some cases, it is unavoidable as a customer wants new features and enhancements. But it is more often the result of poor planning and poor practices.

The best method is to design the structures first before construction begins. Just as you wouldn't build a large business office complex without plans, building a complex structure to house the data of the business also needs a blueprint. Flow charts and/or process maps are essential. Some design elements may be new and need some "proof of concept" preliminary design and testing - can I make that form in xdialog, for example.

This means much of the original work isn't writing code or making tables and forms, but sitting down and building "blueprints". You hire the "construction company", the programmer, when you know what to build. A good database designer, which is very different skill than being a good programmer, starts by verifying the needs and goal of the end user. Then some sketches are made of the concept. When the user approves the concept sketch, then the building design parameters and specifications are established. Finally a detailed blueprint is done, with all of the wiring and plumbing. There is one more step before construction starts, and that is establishing the timetable and construction process flowchart. Finally, construction (programming) begins.

When the end user was us, it didn't matter if the process didn't work smmothly, or the end result had patched "wiring". We were only wasting our own time and money and could fix the wiring when it didn't work. But if you are selling the building, patched wiring and plumbing doesn't work. A simple home doesn't need the complex design of an office building, but it still needs some design and blueprints.

Would you buy a car with a different size tire on every corner, and a different color on every fender? Sorry, there was no room for the headlight on the front, so I put it on a stalk on the roof. That is what many programs look like without planning and design. It is called database design, not database construction, for a reason.

Jerry

[Scott Emerick]

RE: Major Problems

Marcel & Jerry,

I totally agree with you 100% about having a plan.

Just to clairify what happened to me in my case.

My calculated fields were defined in field rules to simply calculate the extention price of a product. The field was called PTOTAL and the "complex" expression was pprice * pqty . The fields were tested and worked as they should.

Somehow during further development of the application, my "complex" expression mutated on its own to something like LOOKUP("PRODUCTS","PID_NO="+CHR(34)+PID_NO+CHR(34),"PPRICE")*PRODUCTS-"PPRICE

The expression was all in caps as shown, which is not how I enter code. I suspect, but can't prove, that during the course of the different patches, some how this was changed automaticly. I do remember a patch that had carried some of the old style set linking into it which cased 1's to be added to table names. This is where I think the problem occured.

I am not blaming Alpha for this or anyone else, but I feel that both your posts slightly hint to my poor planning or poor design, which in this case is just not so.

Sometimes things happen beyond anyones control. I was lucky enough to track and isolate the problem thanks to my backups.

What have I personally learned from this?
1) BACKUPS ARE LIFESAVING (Like we all didn't know this already)
2) When a patch is applied, test everthing ALL over again before continuing development.
3) Even though it worked yesterday, test it again today.

Scott

[JerryBrightbill]

RE: Major Problems

Scott

I was making a generic statement and I think Marcel was also. Some on the board have been a little touchy lately, but I certainly didn't intend it as a comment on your issue or work style. Obviously, you used good troubleshooting and found the problem.

We all fall victim to the problems of complexity. Many times I make a change and don't record it, or change the plan in midstream and forget to make corresponding changes. Some have taken months to show up. Any possibility that you tested a similar expression at one time, but deleted or changed it? Do you have a similar expression anywhere on a form or other code? Perhaps attached to an object with the same name as the field?

I don't see any reason a patch could have made the change. Alpha might change the capitalization in an expression or other saved code. However, a corrupted data dictionary certainly could result in weird stuff happening since that saves the field rules as well as layout designs, etc. Every time I think I have seen the strangest result from corruption in either my code or someone elses, another oddity pops up. That isn't the developers fault or the programs fault, it is just something that happens from circumstances. That is one of the reasons compacting during design is so important (soap box time)

Jerry

[Scott Emerick]

RE: Major Problems

I am sorry if I came across wrong ... I didn't mean to be touchy.

Just frustrated

My Apologies to the board.

[JerryBrightbill]

RE: Major Problems

Scott

No apology needed. I think you posts were quite appropriate and being frustrated when something seems to stop working for no apparent reason is a natural response. Sometimes followed by anger, throwing of small objects......

Jerry

[mronck]

RE: Major Problems

Totally not a problem Scott.
Indeed my remark was meant to be general here.
The remark was made, because I struggled with serious strange behaviour in embedded browses myself this week, and ended up concluding that it wasn't Alpha that caused it, but my lack of planning.
So it was sort of meant as a self answering question getting focus back to planning.
It was not meant to specifically be an answer to your situation.

I guess some critic remarks can be made to the patch-policy of Alpha. In the past we have seen patches following up eachother to fast in order to repair patches with problems. Looks like Alpha has a planning issue themselves, I hope they don't produce patches 'from the hip'. I always install patches the moment I see them.
Maybe it would be wiser to wait a little and see if something serious comes up with a new patch, and install it if not. I know you can always get back to an older patch, but time is precious.....

This forum is most of the time handling ad hoc problems, I for myself would like some more theoretical or general issues as well, like the comment of Jerry. Most things I knew, but not all, and it gets you back thinking again.
I have something like a masters degree in accounting and in my education also got wiser on informatics. But knowledge is very rapidly getting older in that field.
Can't hurt to keep eachother up-to-date.

Have a good weekend guys,

Marcel

[Peter.Greulich]

RE: Major Problems

throwing of small objects......my a**!

You mean like throwing my computer through* the window!
:)



*as contrasted with throwing out the window, which implies you actually opened the window first.

[Bo Vandenberg]

RE: Major Problems

Planning, Design and Outline have very real pragmatic advantages for billing as well. Speaking only for myself, my temptation is to work harder and make problems dissapear rather than describe them.

This practice can really create a communication gap with your customer\employer. You may believe yourself to be really going the 'extra mile' out of dedication but all your client knows is they can't reach you and the product hasn't arrived.

Some of my friends swear by a 'functional spec' of a program before writing begins. That is a mock up of each screen, basically every button, where things are and what they are going to do. The spec is sometimes more work than the program because it is written to include the needs of the customer. They collect half their fee upon agreement on the functional spec.

What systems do you folks use????

Bo