fnCheckForField() DESCRIPTION This function searches a particular record-set for the presence of a particular field. The function returns a boolean value. This function is designed to be used in an Microsoft Active Server Pages environment with the ActiveX Data Objects (ADO). The database field (most probably in a Microsoft Sql Server Database) is denominated by its name. It a field of that name is present in the recordset, then the function returns true, otherwise false. This function does not allow for searching with patterns only for literal string names. EXAMPLE <%@ Language=VBScript %> <% Response.Buffer = true %> <% '-->-->-->-->-->-->-->-->--> dim adoCon dim adoRs set adoCon = Server.CreateObject("ADODB.connection") adoCon.Open "DRIVER={SQL Server};SERVER=203.62.157.199", "sa", "max" adoCon.DefaultDatabase = "mjbdata" set adoRs = Server.CreateObject("ADODB.recordset") adoRs.ActiveConnection = adoCon sQ = "select * from vbtojsconversion" adoRs.Open(sQ) Response.Write(fnCheckForField(adoRs, "VBpattern")) '--<--<--<--<--<--<--<--<--< %> RESULTS true PARAMETERS adoRs {ADO recordset) The recordset to scan for the presence of the field name sFieldName {String} Contains the field name to search for. STATUS: appears to be working. DEPENDENCIES fnErrorMessage CODE LAST MODIFIED 11 April 2000 PROGRAMMER Matthew Bishop LOCATION http://www.geocities.com/matth3wbishop/eg/asp/ DOCUMENTATION http://www.geocities.com/matth3wbishop/eg/asp/ COMMENTS: small utility function This function, to my way of thinking, is actually very successfull. It only attempts to do a simple thing, does not have many parameters, is not very customisable in its behavoir, and yet it reliably does what it is supposed to do. It fulfills its 'contract' and it makes programming easier and more readable. In my opinion, it is more successful than other ASP functions which I wrote, such as fnDataSELECT, and fnDataRADIO because it does not try to do too much. It obeys the unix philosophy of 'do one thing and do it well'. For example the fnDataSELECT function accepts a string parameter which could be a relational database table name, an sql query string or the name of a stored proceedure, and the function has to work out which type of string it is. This leads to bugs and problems with the function and unnecessary complications. The moral of this story for me, is that a programmer should not be afraid to write functions or classes which are less 'general' or 'abstract' than they might be. While the alure of the general has an intellectual appeal, especially after excessive amounts of coffee, in practice, it is easier to go from the specific to the general. It is better to write several more specific functions which work and are known to work than to write one general function which may or may not work. Many people would disagree with this.