disappearing forms

[Rui Carvalho]

RE: disappearing forms

I have had missing forms before. What has helped me is to drop the table that that form is attached to from the database and then add the table to the database. At that point the forms/reports return.

Rui

[JerryBrightbill]

RE: disappearing forms

Allen

When a form goes "missing" there are a limited number of reasons. Either the form was accidentally deleted (been there, done that), the form became corrupted, the table data dictionary has become corrupted, or the table was overwritten. The first problem has no cure and is very painful if you don't have a backup. The second two can almost always be prevented by regular compacting of the database when in design mode.

The third is more interesting. Certain operations will overwrite an existing table and will "remove" any forms. For example, if you import directly into a table, a new table is created, and any existing forms/layouts are gone. If you use the genie to build an import, the data is first imported into a temp file and then appended to the existing table, which doesn't damage it. In a copy, you can specify if the data dictionary is overwritten. If it is, all layouts are lost.

The best solution to prevent a recurrence it to keep regular backups, and compact often when making changes. If I make any significant changes to a form, report, etc, I compact before leaving the database. The problem is that the previous designs are no overwritten, just deleted. And just like deleted records in a table, you have to periodically remove the "junk" the layouts are also just memo tables, which must be treated carefully. But if you compact regularly (throw out the junk), you should have very few problems.

Compacting isn't needed on a production database since you aren't changing the forms and other layouts, just data.

Jerry

[Allen Krause]

RE: disappearing forms

Thanks Rui:

That did it! I dropped the underlying table from the database and then added it. The form magically reappeared.

Allen Krause

[brainey]

Missing Forms

I have also had the "missing form" problem and none of these solutions seems to work for me. The .sem file is gone from the directory, not councsciously erased. Seems to occur when taking a USB hard drive from one machine to another. The DB will refuse to open with various errors, some relating to missing or unfound memo files. I am able to reconstruct the DB eventually but the form files always are lost, reports are always recovered. This has happened more times than not. Last evening, I tried to back up the DB before removing and it kept telling me I had a table open but I did not and there were no temp files in the directory. I was offered to opportunity to skip the offending file but it was the main table in the set.... not an option for me.

[Tom Cone Jr]

Bazella, the only way I know of to assure complete portability for a database is to store all files for the database in a single folder. (I don't even use subfolders of the folder. Literally use only one folder). Your description of the error messages you're seeing suggests to me that some of your tables are located in folders other than the folder where the database dictionaries are found (the folder where your ADB file is stored.)

If everything is in one folder it's easy to zip the contents and copy the zip file to safety, thereby manually creating a backup.

Concerning last night's attempt to backup your database, Windows will report files still open if they were opened but not properly closed. Orphan files can be left "open" when the database closes. A more likely explanation for this is that you're running the backup from a form that's still open. While the form is open, the table or set supporting it is also open, and cannot be backed up.

-- tom

[brainey]

Thanks Tom,

I don't think any of these apply. The DB was all contained in one folder. I have done this over and over. When it happens, I typically create a new folder move the old files, create a new DB and add everthing back. I get the data after bumping around a bit but forms seem always to disappear. Reports hang around. I usually get an error that relates to a memo field but the tables rarely have a memo field in them. That leads me to believe a supporting file has been damaged or lost (a big problem with this product and so many supporting files to bother with and to ensure they all stay nice and pretty where they belong. I have a WD 40 g HD that I use to make my files portable. Only the A5 appear to ever get damaged. Of course, when damage occurs, the DB will simply not open though all tables appear intact. Some, however, will not open in A5 unless I open them individually. I think this in turn may damage them. Also, I have tried opening and saving using Excel (DB4) and usually does not help. It is very discouraging to close down a databse and think all is well after sevral hours work and then reopen it a hour or so later on a different or sometimes the same machine and it will not even open. Years of working with A4 almost never produced such a problem and is what really sold me on Alpha. But, now, it just does not appear to be as stable a product. While I am but a simple user, I could see many things I might do differently if I had a choice. Compared to other products, it is easy to use and powerful. But, what good is that if you keep losing layouts where all the work really is. I don't do coding nor do I really care to along with the easy to use learning curve. Other than this, anyone who thinks the ease of use factor does not exist, probably has not taken enough time to learn the product or never used dBase type products. My staff programmer likes MS Access because he can code to his heart's content though he uses several database products. Often, I ask him to produce things for me in an pre-existing Access application that seems pretty easy to me in A5. Then, the reply comes that it is not quite so easy to do in Access or he will need to research it. Anyway, so much for the tree stump acolades. Bottom line.... when I close a DB, I want to feel assured that no matter when or on what machine I reopen it, it will be there in tact and ready to be used. The intent of the DB was/is to gather and update information in the field and on the run and if it ever works consistently, will be used to capture personal and training data on emergency first and secondary responders within several response organizations. So, it has to be dependable and work consistently or I guess I look elsewhere. I really don't want to do that. So, folks, HELP!?

[Tom Cone Jr]

Bazella,

I never have this problem. I move files back and forth from the office to home on flash drives all the time.

I use pkZip to zip my database folder. Since the folder contains ALL necessary files I never lose forms or other layouts.

Forms are stored in the dictionary files for each table or set. If the form is based on a table it will be stored in the dix for that table. If the form is based on a set of tables, it will be stored in the dix for the set. Ditto for label, letter, browse, and report layouts.

If you separate the data files (DBF, CDX and FPT file extensions) from their dictionaries Alpha Five will not complain. Instead it will automatically create new empty dictionaries for each when the database is next opened. Empty dictionaries do not of course contain your saved layouts. At that point it will seem to you that you've lost your forms. "They've disappeared!". The data is present, but the layouts are not. I suppose it's possible something else is going on at your location, but in my experience the sequence I've just described is the most likely explanation for what you've been experiencing.

As others have noted, it's possible to write over existing dictionaries doing an "import" operation, but you haven't mentioned this as something which is happening immediately before you "lose" your layouts.

If the layouts aren't there, it's because the dictionaries have become corrupted, or were omitted.

I suggest you examine the Table/Sets page of the control panel for your database. Use the "Details View" and carefully study the data path information this returns. You can see each physical folder that Alpha Five is using in your database. Verify that they are identical and that they are the same folder where your ADB file lives.

My 2 cents.

-- tom

[brainey]

forms disappear

They are all in the same folders but what I found was that some were missing e.g. sex and sem for both table and set of same name. I tried getting them from an earlier backup but I think that may do more damage than help. I am sure I do not yet know enough about the file structures and troubleshooting yet to figure this all out. Some apps. have troubleshooting and repair stuff built in and that is easy to use. My staffer has been playing with some of the scripts for that but has not yet reached a level of proficiency that will help me out. Needless to say, I am frustrated. Why only the forms and why could I not back it up last evening. I always try to keep all related files in a single folder. But, now, I have played around copying stuff back and forth so much I fear that if they were there, they are gone now. Best possible thing is not to lose them at first. It has happened probably 9 out of 10 times that I go from one machine to the other. By the way, does HD space on the machine itself (where the A5 resides) need a certain amount of space to work properly? Mine probably has less than 2g available. Also, when I try and access it at work, I use V6. At home, I have V7. Make a difference? Other DBs don't seem to know the difference but are relatively small and most with few tables in a set; if even a set.

[Tom Cone Jr]

My personal practice is to never name a set the same name as a table.

Did you inspect the physical paths for each table as I previously recommended?

-- tom

[sbatncpl]

Disappearing forms in A5V6

The database crashed, for whatever reason, now the forms are not available. I downloaded A5V7 and EVERYTHING was there. I have two licenses for A5V6 and opened the database in question, again, EVERYTHING was there.

How do I retrieve the forms on the first machine using A5V6?

Many Thanks

s. boggs

[Doug Page]

Brazella,

Just a thought. It almost sounded to me that you are actually "running" and "designing" the app ON the USB drive. I have found many times that I do not trust USB drives for operations like this. They are great tools for copying to etc. but can sometimes be dangerous to actually run programs on especially if they are of an older variety. If this is the case then the best thing to do is as Tom is suggesting above. Develop and run your app on the computers hard drive and then zip up the files in the directory to your USB drive. This will also make sure that you have a copy around if something does go wrong.

I might also suggest a program called SyncBack that will keep directories in sync and can also zip them to your USB drive.

HTH