>>>>>In SDT, is it possible to push out a change where only the table field orders change, but there
>>>>>are no other changes in the table?
>>>>It's been a while since I tried that but I believe so.
>>>>Doug
>>>
>>>I'm told by my co-workers that this does not work properly, or reliably, and they have been adding
>>>fields to the end of table structures as a workaround.
>>>I guess my question is: is this a feature you explicitly support?
>>>Is SDT still supported?
>>
>>What does it matter where the fields go in the structure? I can see it being an issue for an import
>>from a sdf file. I often import into a temp cursor - which matches the text file and then import from
>>the temp cursor into the actual table - since that works by field name.
>
>
>We have a maturing application which uses SDT. It is well developed, well debugged, well in use. I was going through finalizing various things related to its overall design to make things standard throughout the system. One such example involves grouping certain related fields together so no matter what table you're in those fields always appear near each other (as in a browse window, or table structure listing). I had asked the other developers why in some tables they were scattered about, and they reported the SDT bug to me.
>
>Our system works properly with the current field order. It's just housekeeping and standards. And, at this point, it may be a bug with SDT which prevents us from moving forward with this aspect of housekeeping.
>
>I've never used SDT before this project. It works exceedingly well though. I'm told we haven't had any issues with it to date. I was also told that field reordering isn't always handled correctly or reliably, and they have avoided it because of it.
>
>Before I push out a change to our clients that may or may not always work, I wanted to know from Doug if it was a supported feature that is known to work. If not, I'll write a mechanical workaround to compensate for the errant/missing functionality.

I'm often telling programmers not to confuse runtime and design time. Example. Why have all functions in one prg? At design time, that seems easy, if you work by yourself. With a team it's a bad idea. A VFP exe doesn't care - is not affected by that - except it requires an additional SET PROCEDURE call elsewhere in the app.

The point is the app should display the columns grouped together. It should not be using raw browses. The devs can do things like browse fields fieldlist. The dev's restructuring the tables for their convenience is interfering with the operations of the company, if you see what I mean.