fnShowRecord(...) DESCRIPTION See fnDisplayRecord instead. This function returns an HTML string to display one record from a database table on a web-page. The record is formatted as an HTML table. The labels for the fields of the data can be specified as can the colours used in the display. SYNTAX <%= fnShowRecord(strOpen, ooConnection, [aaConnect], [aaLabels], [aaColourInfo]) %> EXAMPLE <%@ Language=VBScript %> <% Response.Buffer = true %> This page tests the function fnShowRecord <% '-->-->-->-->-->-->-->-->--> dim adoCon dim sQuery set adoCon = Server.CreateObject("ADODB.connection") adoCon.Open "DRIVER={SQL Server};SERVER=(local)", "sa", "" adoCon.DefaultDatabase = "pubs" sQuery = "SELECT * " & _ "FROM publishers " & _ "WHERE pub_id = 0736 " Response.Write fnShowRecord(sQuery, adoCon) set adoCon = nothing '--<--<--<--<--<--<--<--<--< %> RESULTS (approximate) The output is a formatted table containing the data from the record selected from the table PARAMETERS strOpen- This is the string which is used to open the recordset If the recordset contains more than one record, then only the first record will be displayed. Alternatively this string can be the name of a table or the name of a stored procedure followed by any ooConnection- This is the ADO connection to the database which is used as the active connection for the recordset. [aaConnect]- This is an array containing the information which is to be used to open the database. This parameter is only used if an open connection is not passed (ooConnection parameter). . aaConnect[0] The database driver type (default: 'sql server') aaConnect[1] The IP of the server (default: '(local)') aaConnect[2] The user name (default: 'sa') aaConnect[3] The password for that user (default: 'max') aaConnect[4] The database name. [aaLabels]- This is an array containing the labels to be used for each of the fields for the table record, including the title which will be used for the record display. These labels default to the field-names for the table. aaLabels[0] the title for the data record aaLabels[n] the labels for the fields of the data. [aaColourInfo]- This provides the information for what colours to use in the record display: aaColourInfo[0] the background colour for the html table aaColourInfo[1] the background colour for the labels cells aaColourInfo[2] the background colour for the values cells. aaColourInfo[3] the font colour for the labels. aaColourInfo[4] the font colour for the values. STATUS appears to be working. PROGRAMMER Matthew Bishop matth3wbishop@yahoo.com LOCATION http://www.geocities.com/matth3wbishop/eg/asp/ DOCUMENTATION: http://www.geocities.com/matth3wbishop/eg/asp/doc/ COMMENTS: If more than 1 record is returned by the query then only the first record is displayed. The function has error handling. The function calls fnErrorMessage and therefore 'fnErrorMessage.asp' must be included. If an array for the field label is passed to the function not all the array values must be specified. i.e: There are complete default handling routines. This function was written during my time as an Active Server Pages programmer in Sydney. I was attempting to develop a well structured API of functions in order to deal with the common Relational Database tasks which were part of my job. Because I was dealing with untyped scripting languages, such as Microsoft Jscript and VBscript, I came to adopt a programming structure which attempted to deal with the lack of structure in the languages themselves. Essentially my efforts were not particularly productive. The philosophy behind my attempts was to separate the code and the html content, which in a sense, is completely against the philosophy which ASP was designed by. The philosophy of this style of documentation was to allow the reader to use it in a number of different 'modes'. For example, there would be the programmer who was already familiar with the function but needed a fast reminder of the parameters to use. This is why the 'example' section is so early in the file. Another type of programmer might be reading more generally to get an idea of what functions were available. The idea is that the reader of the documentation would not at any stage need to look at the source code for the function. This is based on the idea that it is difficult for a programmer to think programmatically on different 'levels' at once. By levels, I mean levels of program logic, with for example, a device driver being 'low level' and an HTTP Servlet being 'high level'. If a programmer is forced to look at the source code for a function, in order to understand that function, then he enters a level of thinking appropriate to that function. In other words his mind becomes filled with the problems and solutions of programming on that particular 'level'. Although this is not a bad thing in itself, I believe that this process impedes the programmer from thinking clearly on the 'higher level' of program logic. If a programmer is to make sensible use of an API he must essentially be thinking on a higher level than that API. I believe that my style of documentation makes that possible. The main issue that contradicts the philosophy behind this documentation is the speed at which API's within the world of information technology change and are made obselete. My approach to documentation and programming in a sense is only useful if there is a certain amount of stability in a given API or field of programming. To read API documentation is an investment of time that only appears worthwhile if it seems that the functions or classes that are being read about are going to around for longer than a year or two. For example, almost all of the ASP functions which I wrote (around about the year 2000) would now probably be considered completely obselete (2003), owing to the fact of the appearance of 'Microsoft .net' ideas. My only defense against this would be that while the specific implementation of the API's (in Microsoft Jscript) would probably obselete, the actual design of the functions is possibly not obsolete. The design of the (very small) API which I wrote is based on experience and thought in tackling similar problems over and over again. While there are probably no blinding insights in the functions, no revolutionary approaches, there is still, in my opinion, a set of valid ideas about how proceedural functions within a HTTP Server environment should be structured. This is not to say that there are not many mistakes and stupidities contained within them as well. However, to my way of thinking, the proceedural (functional) programming process is more forgiving of mistakes in design than is the Object Oriented approach. A badly designed and concieved function does not destroy the usefullness of a function library. In fact a badly thought out function, as I see it, usually leads to a better one, because the constant use of the poor function continually highlights its failings and encourages the writing of a better one. On the other hand, a poorly designed object class can often 'drag down' many of its 'adjacent' classes, that classes that use the bad class and are used by it. I am clearly aware that my thoughts in this regard place me completely out of the main stream of current thinking. As I see it, the problems of programming are not really technical or logical problems, but essentially are problems involving the action of entropy on systems of human thought. Object Orientation is an attempt to counter-act the play of chaos on human-ordered systems. As many computer scientists no doubt have pointed out, there is no rigorous way to 'prove' that a function or class does what it is supposed to do. Essentially we can only know that something is going to work if we can understand its machinery. It the case of a large program, the only way in which to understand its 'machinery' is to break that machinery, or logic, into small enough chunks so that the human mind can deal with them. Computers allow us to do that with two main mechanisms: the 'indirect addressing' mode of integrated circuits which essentially allows the mechanism of the 'function' or 'proceedure' and the development of assemblers and compilers which allow us to give units of code names. To my ludditical thinking these are the only things that are truly necessary to conquer computer chaos. But I am probably wrong.