Corrupt Memo fields again

[Jeffrey Twitchell]

I have tried the duplicate and append that has worked before but with no success- I keep getting corrupt arena messages. I tried the divide and conquer trick while appending but found that there are too many errors to be practicle to fix this way. I tried Mel's script but get unexpected character error's on numerous lines of the code. I tried importing the table as a corrupt Dbase table to find memo fields data being replaced with the actual memo address. I tried viewing the .dbf file with word pad to search for obvious problems.

Help?????

I am about to give up on memo fields altogether. The only way to catch these problems before it is too late is to keep packing the table and checking to see if the .ftp file is growing. NOT a good solution in my mind - you still have to find the problem.

I also would like to know if there are any A5 V4 consultants in our area - Portland, ME. Our business requires more of my efforts in other areas and I need someone to maintain and upgrade my rather large application.

[whanigsberg]

RE: Corrupt Memo fields again

Jeffrey:

I don't understand it. Some people have all kinds of problems with memo fields and others never do. I'm in the latter category which is certainly dumb luck as I don't know why I never have problems.

I must say, my application does not have to withstand furious, multiuser data entry into its memo fields.

For both of your issues (memo fields and consultants) it might help if you told us what type of application you have and how you use memo fields.

Bill

[Michael Humby]

RE: Corrupt Memo fields again

Jeffery,

My only experience of swollen memo tables is when the .dbf has been separated from the associated .fpt files. This can happen when moving files around. Is this happening with you.

Michael

[Jim Chapman]

RE: Corrupt Memo fields again

Hello Jeff,

>>I am about to give up on memo fields altogether.

[Jeffrey Twitchell]

RE: Corrupt Memo fields again

If I move files they all go together as I keep all files for an application in one directory. I suspect that my problem is the same as Dr. Waynes. I have the possibility of 6 user working putting information into the system at the same time. I have tried to limit the users that have access to the parent table-which is a table with three memo fields. This parent is the one with the most problems.

[Jeffrey Twitchell]

RE: Corrupt Memo fields again

We are a water treatment company and I have designed the database to handle - lead and customer information, activity information- for lead tracking, proposal writing, test result information and service order writing and follow-up. We have version 4.5 and 4.5 runtime for the work stations. The application consists of a parent and child tables. The parent is linked 1 to many in a tab form that I created before alpha 5 had it available. It is really one large form that clicking on a tab force the focus to another part of the form that has the same tabs only with the new view making the tab appear on top. I have repeated the tabs 5 times down the form so scrolling down would give you the same view. I use 3 memo's in the parent which is really a lead information sheet. The children are things like a proposal table for the lead(memo field used for the desription) , activities table(memos again), test result table from our lab, test results from outside lab, and a service order table(memos again for requests and resolutions). This allows a user to have access through one form for all the information on a customer. The memo fields I have trouble with are those in the parent and sometimes those in the activities table. I can't recall having a problem with those in the proposal table and service order table. Obviously the parent has the most accessing at one time and the next most accessed is the activities. The activities is where all contact - phone, letter, fax etc. is kept. I am thinking of using Dr. Waynes approach on the activities to prevent entry diretly into the browse table. This may solve this problem and I am thinking about creating a separate child table is one to one linking for the memos in the parent. This would maintain the integrety of the parent data and probably help with the memo - at least I won't lose all of the memos on corruption.

[Jeffrey Twitchell]

RE: Corrupt Memo fields again

We are a water treatment company and I have designed the database to handle - lead and customer information, activity information- for lead tracking, proposal writing, test result information and service order writing and follow-up. We have version 4.5 and 4.5 runtime for the work stations. The application consists of a parent and child tables. The parent is linked 1 to many in a tab form that I created before alpha 5 had it available. It is really one large form that clicking on a tab force the focus to another part of the form that has the same tabs only with the new view making the tab appear on top. I have repeated the tabs 5 times down the form so scrolling down would give you the same view. I use 3 memo's in the parent which is really a lead information sheet. The children are things like a proposal table for the lead(memo field used for the desription) , activities table(memos again), test result table from our lab, test results from outside lab, and a service order table(memos again for requests and resolutions). This allows a user to have access through one form for all the information on a customer. The memo fields I have trouble with are those in the parent and sometimes those in the activities table. I can't recall having a problem with those in the proposal table and service order table. Obviously the parent has the most accessing at one time and the next most accessed is the activities. The activities is where all contact - phone, letter, fax etc. is kept. I am thinking of using Dr. Waynes approach on the activities to prevent entry diretly into the browse table. This may solve this problem and I am thinking about creating a separate child table is one to one linking for the memos in the parent. This would maintain the integrety of the parent data and probably help with the memo - at least I won't lose all of the memos on corruption.

[Tom Cone Jr]

RE: Corrupt Memo fields again

Jeffrey,

Your idea of offloading the parent table memos to a child table, linked one to one, makes sense.

I have to say though that your description of the layout itself is unique. If you really do have the same tabbed subform included in your form's layout at five different places, you might want to rework the design to simplify things. In fact, it's often a good idea, especially in a multi-user setting, to avoid trying to do data entry into forms based on complex sets. Are you familiar with Dr. Wayne's article on 'Simplifying Your Applications"... at www.learn alpha.com ?

-- tom

[whanigsberg]

RE: Corrupt Memo fields again

Are you saying that you have the same memo field in multiple objects on the same form? If so, I would simplify by using a button or other control to shift focus to a single instance of the memo field.

Bill

[Jeffrey Twitchell]

RE: Corrupt Memo fields again

Yes I do. This is being changed as we speak. As a matter of fact, I am putting the memo's in a seperate table and then accessing them using a set.

[Jeffrey Twitchell]

RE: Corrupt Memo fields again

It is one form and the fields are all unique at each section of the form. The form only looks like a tabbed form. When you click on a tab the focus moves to the part of the form with the information you want. The tabs are really only buttons that scroll the form up and down. The window is sized so you only see the part of the form you want. The only repeated information on the form are the buttons that look like tabs.