Re: Combo box question

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thank you for your reply.
To re-iterate. I wanted to exclude the last entry in the table purely on the
basis that that scheme was not yet in use, therefore I did not want the name
of the scheme to appear in any combo boxes that lists that particular set of
schemes. Yes, I am very well aware of other methods of excluding entries in
a database table, however, as a fast method, I just wanted to exclude this
last entry in an unordered recordset, whilst at the same time not having to
re-write my generic function to exclude the entry...lazy yes..permanent no.
That's why I asked my original question. The recordset does not needed to be
ordered.
I wrote the small look-up table because this list of schemes crops up over
quite a few other forms. I see no sense in hardcoding this list innumberable
times when I can get the same information from a simple table, and an
equally simple function in a class module. Your solution of hardcoding the
list of schemes, to me, would be infinately more complicated to change if a
new scheme were indeed added. Yes, nothing is permanent, and a new scheme
may be added at some time in the future. To track down each form that
references this list of schemes, and then amend the hardcoded list, would
take ages. My method simply entails me adding a new scheme to the bottom of
my small look-up table. Maybe I'm wrong, but the table seems more logical to
me.
The excluded scheme is now in operation, and my code al la Michael Cole's
reply has been amended to include the full list now. Simple. I just wanted
to exclude the last entry. My programme, in numerous places, does include
the various exclusion methods that you highlight for other database tables,
and numerous tables include a boolean value to specically exclude
"redundant" methods/reagents/participants etc. After nearly 20 years of
database programming, I did manage to learn a few little tid bits.
"Russ Holsclaw" <russ@xxxxxxxxxxxxx> wrote in message
news:ul91ICcoFHA.3304@xxxxxxxxxxxxxxxxxxxxxxx
> I apologize for my lack of tact.
>
> But, if the list is *forever* unchangable, why would it be kept in a
> database?
>
> If the list is truly inchangable, it would make more sense to simply
> hard-code it into the program, rather than go through the formality of
> reading the entries from a database table.
>
> In 38 years as a programmer, I've learned that nothing is ever
unchangable,
> especially things as ephemeral as "QA Schemes". :-)
>
> Assuming that it could change (however unlikely you may think that is), it
> would make sense for the program to continue to be valid after those
> changes are made, so as to minimize the impact of change.
>
> By accepting the assumptions on which both of the "solutions" are
> predicated, you have condemned yourself to having to change both the
> database, and, almost certainly, the program, to make any change.
>
> I was only trying to caution you about the implications of these two
> methods, based on the fact that you are reading data from a database,
which
> is normally quite mutable, by definition.
>
> In particular, a table in a relational database is normally supposed to be
> regarded as an unordered set, unless you are looking at a recordset that
> was explicitly ordered via an "ORDER BY" clause in SQL. Therefore, any
> table with the same set of rows is considered to be equivalent, regardless
> of which is "first", "last", "next" or "previous".
>
> It makes more sense, therefore, to exclude the one member of the list that
> happens to be last (in the current table) based on criteria other than its
> position in the table.
>
> What would make the most sense, in the context of a database, would be to
> make this exclusion as the result of a "Where" clause in your database
> query, establishing whatever criterion it is that makes you want to
exclude
> it. Since you didn't say what that was, I can't be any more specific than
> that, except to say that if the "excludability" of it cannot be determined
> by the data in the row, then it would make sense to add a field ...
perhaps
> a simple Boolean ... that conveys the semantic that corresponds to the
> reason you're excluding it.
>


.

Relevant Pages

  • Re: Looking for a little longer-term (offline) help than a couple of newsgroup replies (posted i
    ... An argument can be made for prefixing the key columns so they can have the same name in the referring table without name clashes, ... FROM lists ... it's mind-bogglingly more important that you be consistent across your entire database than that you use a particular scheme. ... Once you've settled on a scheme, never deviate from it no matter how stupid it is and never brook arguments from people who want to point out that it's stupid (unless they're just doing it to make sure the next database will be less so). ...
    (microsoft.public.sqlserver.server)
  • Re: Trend Micro Folder/File Exclusions (SBS2003 R2)
    ... Active Directory database files = C:\WINDOWS\NTDS ... Windows SharePoint Services ... X:\<AV application folder> ... %systemroot%\sysvol Exclude ...
    (microsoft.public.windows.server.sbs)
  • Re: Trend OfficeScan - Recommended Exemptions?
    ... Active Directory database files = C:\WINDOWS\NTDS ... Windows SharePoint Services ... X:\<AV application folder> ... %systemroot%\sysvol Exclude ...
    (microsoft.public.windows.server.general)
  • Re: SQL and Anti-virus
    ... Definitly exclude the database files and I would ... also exclude the database and transaction log backups and the SQL Server ...
    (microsoft.public.sqlserver.server)
  • Re: SQL and Anti-virus
    ... Definitly exclude the database files and I would ... also exclude the database and transaction log backups and the SQL Server ...
    (microsoft.public.sqlserver.setup)