Whether the column you are trying to display is read-only or not I still believe a lookup is the answer, the only difference being that for the read-only case you need to ensure that the lookup, however it is implemented, is set so that it disallows editing/changing.

I tried using BOs based on views when I was getting started with Strataframe, and found that it just became too complex if I needed it to be updateable. That is not to say it can't be done, and in some places is preferable, but I wouldn't use one to try and maintain a table.

My experience with Devexpress is very positive, but I have no experience with alternatives. Their support is good (though not as good as Strataframe). There are a reasonable numbers of devexpress users on this forum, and has been considerable discussion in other threads, so I suggest you do a search.

Hope this helps.

Peter

I would then use the FillForComboDisplay as the method to populate the combo...and the ph_pk would be the Value Member which is bound to the foreign key field.

BTW, Peter, thanks for your nice words regarding our support! 

As you may have noticed, we have a wrapper for both DevExpress and Infragistics.  Ultimately we use some of the Infragistics (after first using DevExpress) controls in our medical software.  But we have create custom controls and continue to extend our StrataFrame controls due to one isolated issue or another.  DevExpress and Infragistics are both good control companies, but we predominately use the SF controls except in areas like the UltraGrid or controls of that nature.  Infragistics also has some good masking controls (i.e. currency) but they still take some tweaking to get it just right.

Thanks very much for your input and suggestions.  I'm making good headway learning SF because of this good support. 

As a small aside, Trent, I notice you include a table prefix in all our field names (e.g.,  Pharmacy.ph_Name).  Just curious how that helps.  Is it to avoid duplicate field names in JOINS?  Since I am essentially rebuilding some VFP applications almost from scratch, I'm open to anything that prevents problems down the road.

Larry

It's kindof funny how when a certain topic comes up it comes up everywhere.  It seems like I have had this converstaion a lot lately

Yeah, prefixes are a really good standard because it can uniquely separate one table from another.  This is a standard that I learned when I first started in the business and it turned out to be a good one.  This is especailly helpful when you start producing more complex queries such as JOINS or pulling values froma SPROC or VIEW.  Say for example that you have a field named CreatedDate in two different tables, you then have to *** an AS clause for every field in the query that is going to return a CreatedDate otherwise you will have an ambiguous field name.  SQL Server is much more forgiving when it comes to naming fields than VFP, but having prefixes has really reduced the complexity of some of my queries over time.

We always prefix our table and column names with a unique three character prefix, e.g. PUNWeight, HPCWeight etc. Not only does it eliminate duplicates names in procs and views it makes code easier to 'read'. Being doing this for years in various database and highly recommend it.

FYI, another convention we use and find useful is XXX_PK, e.g. HPC_PUNID, for all foreign key relationships, where XXX is the standard column prefix for the table and PK is the Primary Key column name in the foreign key table. As you can see we always name our Primary Key values as the table prefix followed by "ID".

Cheers, Peter

Regards,

Gerard