Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Feature is not supported for non .DBC tables

Status
Not open for further replies.

dmusicant

Programmer
Mar 29, 2005
253
US
I open a Foxpro table EXCLUSIVE in my VFP 9.0 Command Window, issue MODIFY STRUCTURE on this table I've used for 25 years, make a few very innocent changes. I change the order of the fields (the order they will appear in the columns of a BROWSE window if you issue BROWSE in the Command Window. I also lengthen a couple of the character fields from 50 to 75 characters, that's all. I approve the changes and get that "Feature is not supported for non .DBC tables" message. There is no hint what that feature might be. Yes, there are some complicated tags on the fields, likely at least one UDF generating a tag. I have no clue why I got the message, though, I don't remember ever seeing that message with this table, this app or any other. There is no DBC associated with this application. It was originally developed before VFP even existed, i.e. in FPW 2.6. I run it in VFP 9.0 these days. It uses a couple of FPW screens IIRC, a whole lot of @SAY/GET kinds of stuff. Ideas?
 
Maybe a field name with more than 10 characters
Or a Default clause

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania
 
The operations you did (change field order, lengthen fields) are all supported by free DBFs, so the change only working for DBC tables must be some change you did unintentionally or you think of it as even more innocent and haven't told it. There also are no limits of char fields lower for free tables than for DBC tables. Yuo might change a legacy 2.6 table to a VFP free table, when you change to varchar.

One thing in seting, which might influnce alterations: The new Dfile you create byaltering is done i the current codepage and collation, but I don't see some, which are only allowed for DBC tables.

Besides longer field names also default values are a DBC only thing. And primary keys, free table indexes only can have the candidate index type.

Bye, Olaf.
 
Well, as a test I did fundamentally the same thing as reported in the OP. I moved a field one line lower in the list of fields in the MODIFY STRUCTURE screen, then increased the two character fields I had changed from 50 characters to 75 characters, this time to 80 characters and saved my changes. This time I did not get the strange message about change not supported for non .DBC tables. I have to think I did something inadvertently last time that escaped my attention. I can't imagine what it might have been, my changes were very simple and straightforward, I didn't monkey around in there.
 
I've never seen that error message before. As far as I know, it's not a standard VFP message. If a particular function is not suppored for free tables, the designer wouldn't let you do it: the relevant items in the dialogue would be greyed out.

That leads me to wonder if you are using some non-standard component somewhere - although I can't imagine what it would be.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
It's error 1580, indeed a native VFP error.

You might be right the designer might not let you make such changes, but what happend contradicts this. he designer might have a bug here or the effect might only turn out due to some settings in the moemtn the DBF is rewritten due to the altering. As I suspected it might be a setting causing this, which the designer does not take into account, so ony the lower level table file creation process crosses a problem.

If it wasn't a free table a DBC event could cause a side effect. Take Stonfield Toolkits events to automatically adjust view definitions with table alterations. That obviously can't be the case here, but what influences DBF file generation anyway? Codepage and collation settings are the ones I thought about. Index expressions might also depend on further settings. Folder/file permissions might cause error 1580 as misleading false positive.

Bye, Olaf.
 
Hi dmusicant

Similar to yourself, I have a table that has been in use since 1992 and I changed 24 character fields from length 10 to length 24 - nothing else. Now 22 of these fields are in my index structure - no fancy indexing, just straight forward CDX files created with the INDEX command. When I exit the MODI STRU I get this same message - it has never appeared before. It appeared about 8 times (just kept clicking OK) and then the table structure was saved. When I went back to MODI STRU, I noticed that several of my index keys were missing. I recreated these index keys and everything is fine (I hope!). The only thing I can say that may be a major factor in this, is that this is the first time I have done this in windows 10. Also, in the course of updating screens (e.g. to cater for the extended fields), I have had a few .SCT files either disappeared or left corrupted (you only find this out of course when you go back to amend the screen layout at a later time). I have had to restore backups and redo the amendments. Again, these problems have only started since I upgraded my 6 month old laptop to windows 10.
 
So, WHY did you those changes when it has worked for so long? When it ain't broke...
 
Hi drdolittle
Quite simple really, the system is for a client I have and when he tells me he needs to extend his product code from 10 to 24 characters, well . . . I don't argue I just say 'okey dokey, easy in Foxpro'. And bearing in mind that his system is 23 years old, in 1992, 10 characters was sufficient for his product code, but now, he needs a little bit more - even his business has expanded in that time!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top