Larry,

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 tend to agree with Peter on the lookups.  We have hundreds of places that a foreign key value needs to be selected or set.  For example, we may have a patient and their preferred pharmacy may need to be selected.  So we may populate a combo box with only the values that need to be used and bind it to the patients foreign key field.  It is always good to create a custom Fill method that only brings back the required fields in this case...no reason to add overhead:

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.

Peter and Trent,

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.

Hi Guys,

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

Hi Larry. Just lurking through old messages and notice that your requirement is something I want to do in strataframe. i.e. Mutile Parents for the one Child  (i did exactly as you were doing in VFP..the IIF in a grid) Did you get a resolution ?

Regards,

Gerard

There will be a new feature coming that allows as many foreign key relationships to setup as you would like....we have been using this for quite some time (through the framework) and will release it to the general public within the next several updates.  This has actaully been discussed on a couple of other threads lately...so I recommend doing a search if you want more details...but in short there will be a mechanism for this shortly anyway.