Faulty field when changing table structure

[PEAK_A5]

Hi

We have a table with 197 fields.

When altering fields in this table we found that it slowed down Alpha 5 (operations go slow, mouse clicks are slow, menus are sluggish when accessed). We found that this issue was only corrected if after any table change we go into the field rules, save and exit. This makes everything run at normal speed. Still not sure why but went with this 'fix' as it was the only thing that worked!

However we were changing one particular field name the other day and this 'fix' did not work. After trying many different things we have found out that we cannot rename the field or delete the field as it causes everything to run sluggish again. However if we changed the field size or type and then go into Field Rules this is fine and works at normal speed. The only thing we appear not to be able to do is rename or delete it.

It seems like this particular field is faulty. We haven't tried all of our other fields but have tried a few others at random and we can change the names etc okay as long as we use our 'fix' afterwards. Therefore it appears to be just this one field at the moment.

Has anyone come across anything like this before?

Thanks

[Tom Cone Jr]

Re: Faulty field when changing table structure

Can't say that I have. You know of course its not necessary to rename a field just to change how the field is labelled in a form or on a report, right? You also know that fieldnames cannot contain "illegal" characters and should not match any of the "reserved words" Alpha set aside for its own use, right?

How about showing us the original fieldname, and then the "new" name that's giving you trouble?

-- tom

[PEAK_A5]

Re: Faulty field when changing table structure

Hi Tom

Yes we know that we don't have to rename them but some of the fields in this database are attached to a code we are using and out of tidiness we wanted to rename this one as we had missed the code off. We then had this issue and felt that we did not want to leave the field in the database if it was faulty for any reason.

The field name is ACTION_TAKEN and we want to rename it to ACTION_TAKEN_IN10

Where would I find a list of the illegal characters and reserved words please? We have heard about them a while ago but don't know the exact words.

Thanks

Fiona

[Tom Cone Jr]

Re: Faulty field when changing table structure

Here's a quote from the helps concerning fieldnames:

Table and Field Names

Alpha Five recommends that table names, field names, and paths to your files start with a letter (A-Z or a-z) and be composed of letters, numbers (0-9), and underscore (_) characters.

NOTE : Do not use tilde "~" or "@" characters in table names, field names, and paths.


Here's a link to the "reserved words".


I don't see anything wrong the original field name you were using.

[DaveM]

Re: Faulty field when changing table structure

As a note, alpha also recommends 10 characters or less for field names.

[PEAK_A5]

Re: Faulty field when changing table structure

Thank you Tom. No the field seems fine, seems no different from any of our others so really stuck on this one.

Thank you Dave. Our field name is more than 10 characters but so are a lot of our others but I will look into it and see if its anything to do with it, although we have used more than 10 in a lot of other databases with no issue.

[DaveM]

Re: Faulty field when changing table structure

the ten characters won't affect your problem. It is a precautionary deal. If corruption occurs, your field names will be shortened to 10 characters for you. I have had it happen. The app will either not run or run to a degree with error(s) flying up everywhere depending on how many misnamed fields.

[G Gabriel]

Re: Faulty field when changing table structure

Are there any indices involving that field?

[MoGrace]

Re: Faulty field when changing table structure

Adding a new field to the end of a table is usually not a problem. But changing a field name sure can be. I had this happen just the other day - the change just wouldn't 'take'. What did work was to add my new field at the end, save and close, then after remapping my forms and indices; go back and delete my old field name. Compacting the table when you are done is also a good idea.

[DaveM]

Re: Faulty field when changing table structure

I don't understand not being able to change a field name like you are describing. I just change over 400 field names in a bunch of tables to get them all to 10 characters for a client with absolutely no problems. Still working on the mapping issues for forms, reports, scripts, etc. Will be for a couple of weeks.

Is it possible another field is dependent on that one for a field rule or something like that?

[MoGrace]

Re: Faulty field when changing table structure

Hi Dave,
No problems except mapping issues for forms, reports, scripts, etc. you say? Why does it sound so easy when you say it?

It may have been a field rule, though I can't remember now. Mostly, I think it has to do with having upgraded an old app thru several versions. The other thing that happens to me frequently during development seems to be memory corruption - where Alpha seems to lose some system functions. So I try to be careful when doing things like this. Eg, I have learned to save and close my work thru the menu system and not just pop an edited form into view mode like I see Selwyn do on his videos. I suspect in his videos, there is no real data to corrupt...

TO FIONA:
Naming a field ACTION_TAKEN_IN10 may not be unique enough since the first 10 characters will be ACTION_TAK. I would probably shorten that to ACTAKE10 or something similar.

[DaveM]

Re: Faulty field when changing table structure

Hi Robin.

I did not mean to pass off the work as quick to do. This app is an older one that I got involved with and found all the field names that were added over the years with many being 20+ characters long. Tables that were close to a gig and a half. I had to split 2 very large tables(one having 400 fields in it) because I don't like over 100-150 tops per table and one that had a very high number of records in it(already at 837000).

That means rebuilding sets, using "copy to" on forms, reports, etc., redoing almost everything and yet try to give the users a similar look and feel. I have found almost a 50% increase in speed so far with most of it using full sized data, so headed in the right direction.

A lot is being redesigned to accommodate the users click and type methods. They were kind enough to make movies of what they are doing using Jing, so I know what is supposed to happen. I can do a lot of the mundane stuff for them with fewer user mistakes as it progresses.

This was also in version 8 and going to 12, so much of the code works, but once opened for a minor change has to be re-set to v12 standards. Amazing a script works in v12 until you change 1 thing and then it does not once you save it in v12. I knew from the past this would be the case though.

[MoGrace]

Re: Faulty field when changing table structure

Dave,
Since I now have 2 'mirrored' apps, I am considering duplicating everything but the data and using that to make my changes then port over to the working apps.

Still thinking that idea thru...

[DaveM]

Re: Faulty field when changing table structure

The first install to the client will be empty tables with no field rules and just appends to get the data in unhampered. That should take about 30 minutes doing one table at a time.
Then install the rest of the app(the supporting files and indexes) with a compact to bring it all to date.
Then they have to install the runtime on 40 computers. I make that very easy for them with a self running(mostly) install. It puts a start icon on the desktop.

I am thinking seriously about using three sizes of forms because they do run several resolutions and some are laptops. Peter wayne and a couple others gave a neat way of doing that.

Sorry, I am working the installs through my mind as I go here. It helps to type it out.

[PEAK_A5]

Re: Faulty field when changing table structure

Thanks for your replies, a couple of us are in next week and going to try some of the above.