none
Using the IN Operator in the Access 2003 Query builder Criteria field

    Question

  • I'm having problems with the IN Operator when I use it in the Criteria field in the Query builder. I have a table that I use to store a couple of Report Filters. When I try to use DLookUp("[Rep_SQL]","qry_ReportParameters","RepPar_ID=1") in the queries Criteria field I usually get a data type mismatch error although sometimes the query runs but nothing is returned. However, If I type the data that the Dlookup function returns "[iMISid] IN (9999991,9999992)" into the same field, the query returns the records that I expect it to. I also tried modifying the filter to omit the "[iMISid]" portion of  the filter but the results are the same - the Dlookup Function fails but typing the filter directly into the criteria field works fine. I also created a dummy field in the query and ran it without any filters just to see if the DLookup Function was returning the correct data from my "Filter" table and that seemed to work correctly. Here is the dummy field "SQL:DLookUp("[Rep_SQL]","qry_ReportParameters","RepPar_ID=1"). For a while I thought that the problem had something to do with the fact that the field that I'm trying to apply the filter to was a primary key field and that the DLookup was returning a text string that the query couldn't deal with. I tried applying a similar filter to a text field but got the same results. This alternate DLookup returns the following value "In ("Program 1", "Program 2")" but again if I manually type in the criteria the query works as expected but if I use a DLookup to plug in the same criteria the query either returns data type mismatch or just doesn't return anything. I know the answer is probably staring me in the face but I'll be darned if I can figure this one out. Any insight to this problem would be greatly appreciated.

    I'm using Access 2003 with all the latest and greatest patches running on a Windows XP SP3 system.

    Regards,

    TJ Cyr


    Tom Cyr
    Friday, October 15, 2010 12:51 AM

Answers

  • Tom,

    Thank you for the clear detailed explanation.  What you have said pretty much reflects the general concept I had alrady understood from your first post.

    Regarding "The Date works fine but the IN Operator statement does not work and I'm not sure why", I tried to explain why in my earlier reply, but it looks like I didn't make it clear.  Sorry about that.  Suffice it to say at this point that the approach you are taking will not work (which you already know), and it has to be re-thought.

    There are a couple of possible approaches you could take here.

    One is to use a table to temporarily hold the criteria values, as you have now, but instead of trying to write a IN clause into a single record, write the selections from the multi-select listbox into separate records in this table.  So in your example you would have 2 records with 9999991 and 9999992 entered in two separate records in the same field.  Then, you can simply add this table to the baseline query that you mentioned, with a join between this field and the iMISid in the core data table.

    The other idea is to use VBA procedure to modify the query.  Something along these lines:
    Dim qdf As DAO.QueryDef
    Dim strBaseSQL As String
    Set qdf = DBEngine(0)(0).QueryDefs("NameOfYourQuery")
    strBaseSQL = "SELECT blabla FROM ..."
    qdf.SQL = strBaseSQL & " AND [iMISid] IN (9999991,9999992)"
    < your code to run report >
    qdf.SQL = strBaseSQL

    Not full and complete solutions here, but I hope you can understand the general concepts I am offering.


    Steve Schapel, Microsoft Access MVP
    • Marked as answer by TJ Cyr Saturday, October 16, 2010 12:26 AM
    Friday, October 15, 2010 6:52 PM
  • Tom, I think you'll need to build the complete SQL string of the query, not just the criteria. You simply cannot pass a comma separated string of values as a Parameter; Access will see the parameter as a single value (a text string which happens to contain some commas), not as multiple individual values. Reread A.D.'s suggestion, it's trickier than it may appear at first glance!

    What I'll usually do in this case is have a "template" query string such as

    SELECT this, that, theother FROM table1 INNER JOIN Table2 ON table1.keyfield = table2.foreignkeyfield

    and use code to append a WHERE clause to it.

     


    John W. Vinson/MVP
    • Marked as answer by TJ Cyr Saturday, October 16, 2010 12:24 AM
    Friday, October 15, 2010 8:58 PM

All replies

  • Tom,

    No, you can't use a function like that.  If I understand you correctly, the function returns this value:
    "IN (9999991,9999992)"
    That is a sigle value, and as you correctly pointed out, it is a string. The query is then trying to find records where the [iMISid] field contains this value:
    "IN (9999991,9999992)"
    There are no such records.  And in this case, you are trying to apply a text criteria to a numerical field.  Won't work.

    So, where is the qry_ReportParameters query getting the values 9999991 and 9999992 from, and how is this being constructed?


    Steve Schapel, Microsoft Access MVP
    Friday, October 15, 2010 1:37 AM
  • I think the answer is a little more subtle.

    The DLookup fuction will return a single value, not a comma delimited list or recordset. If the filter is such that many values could be returned, only one will be, and which is returned may not be repeatable between calls.

    Instead of using the dlookup, why not use a select statement?

    Friday, October 15, 2010 2:05 AM
  • Steve and Chris,

    Thanks for your responses. I'll try to clarify exactly what I'm trying to do and why I'm doing it this way.

    In the Beginning: I have several Reports that I generate from my database that share several Queries that collect and calculate information that goes into these reports. Each Report has it's own Crosstab query that does the final computations for that particular report. In order to do some user selectable filtering on each of these reports I set up a Form where the user can select various programs to be included in the report as well as a Date field. This Form is modeled after a form that was done by Allen Browne (http://allenbrowne.com/ser-50.html) using a Multiselect Listbox. This form was used to launch the desired report using a button on the Form. When depressing the button, the code behind the Form would pass the filter information to the report like this: "DoCmd.OpenReport strDoc, acViewPreview, WhereCondition:=strWhere, OpenArgs:=strDescrip"

    The strWhere parameter normally looks like this "[iMISid] IN (9999991,9999992)" where "iMISid" is one of the Primary keys in the table that the info is coming from. The OpenArgs parameter contains the text strings that describe each of the programs selected in the Multiselect list and are displayed on the last page of the report to tell the user what programs were used to generate the data in the report. All this works perfectly every time.

    Now requirements have changed: The User wants to change the way the report delivers the data. Before it was based on Programs (these are the numbers you see in the IN statement above) but now they still want to filter on programs but instead of having programs listed in the final report, we want to group by Counties. To make a very long story short, I needed to get the Program numbers (iMISid field) out of the Crosstab query that feeds into the report. This means that I can no longer pass the filter on to the Report in the Where clause because the iMISid parameter is no longer available in the Query that the Report is based on. If I add the iMISid parameter to the CrossTab query, the computations and grouping are off.

    My Solution: Since the CrossTab query has a couple of underlying queries that it uses as its data source AND one of these queries just happens to be common to all the Reports that I need to generate I thought it would make sense to move the filtering to that one query and forgo the use of the Where clause that is passed to the reports when they are launched by the Filter Form. What I did was to create a table to hold the strWhere clause generated by the underlying code on the Filter Form. I also based the Filter Form on a query that "talks" to this filter table and forces only the 1st record to be used in that table. I also stuff into this table the date parameter and the Program desciptions that were passed as the OpenArgs to the Report. Now, using the DLookup function, I can pull from this Filter Table the Date and the "IN Operator" information that was created by the code in the Filter form and use it in the Criteria field for the appropriate field that I want to limit the query results on. The Date works fine but the IN Operator statement does not work and I'm not sure why. If I use Copy and Paste and take the IN Operator statement that is stored in the Filter Table and Paste it into the Criteria field in the Query, everything works as expected. I would assume that Copy/Paste is treating this as a text string. This is exactly what that IN string looks like (Copy/Paste) right from my Filter table: [iMISid] IN (9999991,9999992) and this works fine if I paste that into the iMISid field in my query but if I use DLookup to do the same thing it boms.

    I also tried creating a Public Function (Get_SQL) but I get the same results. Also, I thought that since the Program numbers were actual numbers and not text strings, maybe I had a problem there so I attempted to use the Program descriptions as the IN Operator parameters since those are all plain text strings but I get the exact same results. It seems that Access does not like IN Operator parameters passed in a DLookup function (or any function for that matter). I must confess though that my Public Function just uses the DLookup at the VBA level. I'm sure that there's a better way to do that. Here is that piece of code (Iwas was frustrated and in a hurry to find a solution when I wrote this):

       Public Function Get_SQL() As String
        'On Error Resume Next
        Dim strRepSQL
            strRepSQL = DLookup("[Rep_SQL]", "qry_ReportParameters", "RepPar_ID=1")
            MsgBox strRepSQL
            Get_SQL = strRepSQL
        End Function

    Thanks for all your help, I really appreciate it

         Tom Cyr


    Tom Cyr
    Friday, October 15, 2010 2:21 PM
  • Tom,

    Thank you for the clear detailed explanation.  What you have said pretty much reflects the general concept I had alrady understood from your first post.

    Regarding "The Date works fine but the IN Operator statement does not work and I'm not sure why", I tried to explain why in my earlier reply, but it looks like I didn't make it clear.  Sorry about that.  Suffice it to say at this point that the approach you are taking will not work (which you already know), and it has to be re-thought.

    There are a couple of possible approaches you could take here.

    One is to use a table to temporarily hold the criteria values, as you have now, but instead of trying to write a IN clause into a single record, write the selections from the multi-select listbox into separate records in this table.  So in your example you would have 2 records with 9999991 and 9999992 entered in two separate records in the same field.  Then, you can simply add this table to the baseline query that you mentioned, with a join between this field and the iMISid in the core data table.

    The other idea is to use VBA procedure to modify the query.  Something along these lines:
    Dim qdf As DAO.QueryDef
    Dim strBaseSQL As String
    Set qdf = DBEngine(0)(0).QueryDefs("NameOfYourQuery")
    strBaseSQL = "SELECT blabla FROM ..."
    qdf.SQL = strBaseSQL & " AND [iMISid] IN (9999991,9999992)"
    < your code to run report >
    qdf.SQL = strBaseSQL

    Not full and complete solutions here, but I hope you can understand the general concepts I am offering.


    Steve Schapel, Microsoft Access MVP
    • Marked as answer by TJ Cyr Saturday, October 16, 2010 12:26 AM
    Friday, October 15, 2010 6:52 PM
  • Tom,
     
        Apparently, you wish to implant a criteria string (having IN operator) fetched from a table / query (using DLookUp() function) into the WHERE clause of a select query.
     
        The desired objective can be realized by enclosing the criteria string in Eval() function. Sample syntax for WHERE clause for number type data is given at A below. For text type data, the syntax would be as per B below.
     
        Note:
        (a) In the source table holding criteria strings, field name (iMISid) MUST be omitted. Simply retain the balance portion, starting with IN
        (b) Sample entry for Rep_SQL field in qry_ReportParameters for number type data would be:  IN (9999991, 9999993, 9999995)
        (c) Sample entry for Rep_SQL field in qry_ReportParameters for text type data would be:  IN ('9999991', '9999993', '9999995')
        (d) It would be a good practice to provide a leading space in the criteria string. However, as an abundant precaution, such a space has been added in samples A & B for the WHERE clause, as given below.
     
    Best wishes,
    A.D. Tejpal
    ------------
     
    A - For number type data
    =======================================
    WHERE Eval([iMISid] & " " & DLookUp("Rep_SQL","qry_ReportParameters","RepPar_ID=1"));
    =======================================
     
    B - For text type data
    =======================================
    WHERE Eval("'" & [iMISid] & "' " & DLookUp("Rep_SQL","qry_ReportParameters","RepPar_ID=1"));
    =======================================
     
    ----- Original Message -----
    From: TJ Cyr
    Newsgroups: Msdn.en-US.accessdev
    Sent: Friday, October 15, 2010 06:21
    Subject: Using the IN Operator in the Access 2003 Query builder Criteria field

    I'm having problems with the IN Operator when I use it in the Criteria field in the Query builder. I have a table that I use to store a couple of Report Filters. When I try to use DLookUp("[Rep_SQL]","qry_ReportParameters","RepPar_ID=1") in the queries Criteria field I usually get a data type mismatch error although sometimes the query runs but nothing is returned. However, If I type the data that the Dlookup function returns "[iMISid] IN (9999991,9999992)" into the same field, the query returns the records that I expect it to. I also tried modifying the filter to omit the "[iMISid]" portion of  the filter but the results are the same - the Dlookup Function fails but typing the filter directly into the criteria field works fine. I also created a dummy field in the query and ran it without any filters just to see if the DLookup Function was returning the correct data from my "Filter" table and that seemed to work correctly. Here is the dummy field "SQL:DLookUp("[Rep_SQL]","qry_ReportParameters","RepPar_ID=1"). For a while I thought that the problem had something to do with the fact that the field that I'm trying to apply the filter to was a primary key field and that the DLookup was returning a text string that the query couldn't deal with. I tried applying a similar filter to a text field but got the same results. This alternate DLookup returns the following value "In ("Program 1", "Program 2")" but again if I manually type in the criteria the query works as expected but if I use a DLookup to plug in the same criteria the query either returns data type mismatch or just doesn't return anything. I know the answer is probably staring me in the face but I'll be darned if I can figure this one out. Any insight to this problem would be greatly appreciated.

    I'm using Access 2003 with all the latest and greatest patches running on a Windows XP SP3 system.

    Regards,

    TJ Cyr


    Tom Cyr

    A.D. Tejpal
    Friday, October 15, 2010 7:14 PM
  • Thanks A.D. and Steve for the replies.

     

    Steve, I'm a little confused. I understand what you are saying but please explain the following:

    First, I created a new field in my Filter Table called Rep_Criteria and it contains the following: 9999991,9999992

    Second, I modified my query such that the criteria now contains the following: In (DLookUp("Rep_Criteria","qry_ReportParameters","RepPar_ID=1"))

    When I run the query I get the same error message - "type mismatch,,,,,"

    But if I change Rep_Criteria to the following: 9999991 or 9999992   -The query works perfectly.

    I guess that I'm having a hard time to understand why a Copy/Paste from the Filter table to the query criteria field works and using a DLookup to do the same thing doesn't.

    Anyway, I'll try to come up with an alternate way to accomplish the same thing.

     

    A.D. I tested your solution A and I keep getting a syntax error. It seems that the query builder doesn't like the word "WHERE" in the criteria field. I tried using solution A in the SQL code directly and it didn't like that either.


    Tom Cyr
    Friday, October 15, 2010 8:39 PM
  • Tom, I think you'll need to build the complete SQL string of the query, not just the criteria. You simply cannot pass a comma separated string of values as a Parameter; Access will see the parameter as a single value (a text string which happens to contain some commas), not as multiple individual values. Reread A.D.'s suggestion, it's trickier than it may appear at first glance!

    What I'll usually do in this case is have a "template" query string such as

    SELECT this, that, theother FROM table1 INNER JOIN Table2 ON table1.keyfield = table2.foreignkeyfield

    and use code to append a WHERE clause to it.

     


    John W. Vinson/MVP
    • Marked as answer by TJ Cyr Saturday, October 16, 2010 12:24 AM
    Friday, October 15, 2010 8:58 PM
  • John,

    Correct me if I'm wrong but what I think y'all are saying is the following:

    Typing "IN (9999991, 9999992)" into my criteria for the iMISid field will work because Access will see the values in parens as a comma seperated list of numbers.

    Using DLookup to plug "IN (9999991, 9999992)" into the same criteria field will not work because Access will see this as a single string parameter and there is no way around this using the DLookup Function.

    I hope I got it right this time around, I know you folks are pretty busy and I hate to keep hammering away at this issue. I'm not sure how I would append the WHERE statement that you mentioned but I think I need to do more research on this.

     

    Thanks everyone for all your help.


    Tom Cyr
    Friday, October 15, 2010 9:28 PM
  • Typing "IN (9999991, 9999992)" into my criteria for the iMISid field will work because Access will see the values in parens as a comma seperated list of numbers.

    Using DLookup to plug "IN (9999991, 9999992)" into the same criteria field will not work because Access will see this as a single string parameter and there is no way around this using the DLookup Function.

    That is correct.

     


    John W. Vinson/MVP
    Friday, October 15, 2010 10:41 PM
  • I was able to solve my problem by doing the following:

    I created a new query that just does a "SELECT * From (thequerythatIwastryingtousetheDLookupIn). This made the query real simple to modify in code.

    In the code where I process the MultiSelect List I added some code that would check to see if there was a Where statement in the above mention simple query and if so remove it then append a new Where clause with "WHERE ((([rqry_Z_Summary Data].iMISid) In (9999991,9999992))); or whatever programs are selected in the list. This seems to work OK. I'll have to add a few more checks in there to make sure that it adds the ";" when there is nothing selected in the list in situations where the user wants everything.

    I've been in the Computer business for 38 years and I can't believe that this was my very first time using a Forum of any kind.

    Thanks everyone for all your kind help and suggestions.


    Regards,
    Tom Cyr
    Saturday, October 16, 2010 12:22 AM
  • Tom,

    There are certainly a number of ways to handle this type of situation, and the details of which is the most advisable approach depend on a number of factors, including the data management requirements of the specific case, as well as the personality disposition of the developer. :-)  I am happy to hear that you seem to have found a solution that works for you in this instance, and I hope we have been able to contribute to your process of arriving at that solution.

    For the record, the ";" as far as I know achieves nothing, and so I wouldn't put too much effort into worrying about that.


    Steve Schapel, Microsoft Access MVP
    Saturday, October 16, 2010 3:21 AM
  • Steve,

    You folks have certainly contributed to the success of my project and I thank y'all for that. Now that things are working I'll be able to get a good nights sleep and that should improve this developers disposition:-).

    The only concern that I had with the ; was to make sure that I had good SQL code so when the database is split and the back-end is moved to SQL Server I won't end up with a few "gremlins" in this database. The code to take care of the ; is now in place and seems to do the right thing in all the tests that I have run so far.

     

    Regards,


    Tom Cyr
    Saturday, October 16, 2010 4:40 AM
  • Tom,
     
        It is nice to see that as per your subsequent post, the problem stands resolved via VBA code.
     
        If the developer is in a position to manage via SQL string in VBA code or programmatic application of filter on a form or report, the task is rather straight forward, as it involves routine concatenation of stored criteria string into the overall SQL string. 
     
        However, it might also be useful to get acquainted with an alternative approach, if it is found necessary at any stage to use stored criteria in a saved query. In such a case, one has to take into account the fact (as already discovered by you) that when a stored criteria string is embedded in the SQL of a saved query, its  elements acquire a dormant state. For example "[MyField] IN (50,100,150)" does not come across as a meaningful clause. The argument for IN clause remain frozen as string "50,100,150". 
     
        For activating such an embedded string, it needs to be enclosed within Eval() function. Moreover, field names, wherever occurring within the criteria string, are required to be replaced by their respective current values, duly enclosed within appropriate delimiters as applicable. This is because, a string argument for Eval() function has to be intrinsically meaningful.
     
        The approach outlined above is demonstrated in my sample db named  Query_CriteriaStyles. It is in access 2000 file format and is now available at Rogers Access Library. Link:
     
        Two styles are covered as follows:
        (a) Criteria string is complete, inclusive of field names and operators.
        (b) Criteria string is partial, excluding field names. Operators are included. In other words it represents the right hand portion of a criteria expression, including operators.
     
        Style (a) has the advantage that it is universal in scope, permitting complex criteria, involving interaction between multiple fields for unlimited analysis of what-if scenarios, while the SQL for saved query remains unchanged.
     
        On the other hand, style (b) is simpler, not requiring any pre-processing of criteria string before application of Eval() function. However, in this case, the  expression is confined to only one field at a time, with separate saved query per criteria field of interest.
     
        For each of the two styles, two alternative methods for fetching the criteria string are demonstrated (either via form control or via DLookUp() function).
     
        The sample has interactive feature, wherein the user can play with the originally stored criteria strings and watch the outcome. At each stage, SQL of saved query currently in force, also gets displayed. Whenever desired, original criteria strings can be restored on click of a command button.
     
    Best wishes,
    A.D. Tejpal
    ------------
     
     
    ----- Original Message -----
    From: TJ Cyr
    Newsgroups: Msdn.en-US.accessdev
    Sent: Saturday, October 16, 2010 02:09
    Subject: Re: Using the IN Operator in the Access 2003 Query builder Criteria field
     
    Thanks A.D. and Steve for the replies.
     
    Steve, I'm a little confused. I understand what you are saying but please explain the following:
     
    First, I created a new field in my Filter Table called Rep_Criteria and it contains the following: 9999991,9999992
     
    Second, I modified my query such that the criteria now contains the following: In (DLookUp("Rep_Criteria","qry_ReportParameters","RepPar_ID=1"))
    When I run the query I get the same error message - "type mismatch,,,,,"
    But if I change Rep_Criteria to the following: 9999991 or 9999992   -The query works perfectly.
     
    I guess that I'm having a hard time to understand why a Copy/Paste from the Filter table to the query criteria field works and using a DLookup to do the same thing doesn't.
    Anyway, I'll try to come up with an alternate way to accomplish the same thing.
     
    A.D. I tested your solution A and I keep getting a syntax error. It seems that the query builder doesn't like the word "WHERE" in the criteria field. I tried using solution A in the SQL code directly and it didn't like that either.

    Tom Cyr

    A.D. Tejpal
    Monday, October 18, 2010 6:24 PM
  • A.D.,

    I downloaded your database and took a look at it. Very Impressive! What your are doing there is a little bit over my head but (correct me if I'm wrong) it looks like you loaded up a table with a bunch of "canned" queries that you can apply to a report to get different results. I'll have to remember this example so if I need this capability in the future I'll model it after your examples.

    I don't think this would have worked for my situation though since I needed a way to dynamically create the query based on what the user had selected on my "Filter" Form. Even though this form is based on a table where I could store the criteria it was just a convenient place for the DLookup to pull data from. I still use this table but it's mostly for debugging. I have a multi Select List, a Limit Date and Fiscal Year for them to choose from. When they click the appropriate button to run their desired report, I build the "Where" statement  from what they have selected and replace the Where statement in a simplified version of the original query. This query is then used by the Crosstab query that the selected report is based on. Originally, I just passed the criteria to the report to do my filtering but I ran into a problem when we needed to filter on the primary key for one of the tables but this primary key was not available in the crosstab query because including the key resulted in incorrect output from the crosstab query.

    I suspect that I could have adapted your example t work in my situation but I think I would developed a more complicated solution.

    Now my next major task will be to migrate the tables to SQL Server 2008. I just hope it doesn't break all my queries. I'm on a fence as far a using DAO or switching to ADO.

    Thanks and Regards,

     


    Tom Cyr
    Monday, October 18, 2010 9:00 PM
  • Tom,
     
        You are most welcome! Considering the circumstances explained by you, the course of action finally adopted at your end appears to be the appropriate one.
     
        Regarding the sample db (Query_CriteriaStyles), it is to be noted that dedicated saved queries (field-wise) come into play only if you opt for partial criteria string that excludes the field names. This style (along with the set of queries having prefix Q_PartCriteria)  has been included mainly as comparative illustration.
     
        The style meriting special interest is the one using full criteria string, as represented by saved query named Q_FullCriteriaFromForm. This single query is universal in nature and REMAINS LITERALLY UNCHANGED, irrespective of the number of fields in source table or the level of complexity in criteria string, which can have multiple field names in various  combinations as needed.
     
        The above query picks up the stored criteria string from text box named CriteriaString on form named F_StoredCriteria_FullString (opened by clicking first command button on switchboard form). This control, holding the criteria string can either be an editable one or still better, hold the combined outcome of other controls (e.g. list box, combo box, text box etc) as per which data is required to be filtered. 
     
    Best wishes,
    A.D. Tejpal
    ------------
     
    ----- Original Message -----
    From: TJ Cyr
    Newsgroups: Msdn.en-US.accessdev
    Sent: Tuesday, October 19, 2010 02:30
    Subject: Re: Using the IN Operator in the Access 2003 Query builder Criteria field

    A.D.,

    I downloaded your database and took a look at it. Very Impressive! What your are doing there is a little bit over my head but (correct me if I'm wrong) it looks like you loaded up a table with a bunch of "canned" queries that you can apply to a report to get different results. I'll have to remember this example so if I need this capability in the future I'll model it after your examples.

    I don't think this would have worked for my situation though since I needed a way to dynamically create the query based on what the user had selected on my "Filter" Form. Even though this form is based on a table where I could store the criteria it was just a convenient place for the DLookup to pull data from. I still use this table but it's mostly for debugging. I have a multi Select List, a Limit Date and Fiscal Year for them to choose from. When they click the appropriate button to run their desired report, I build the "Where" statement  from what they have selected and replace the Where statement in a simplified version of the original query. This query is then used by the Crosstab query that the selected report is based on. Originally, I just passed the criteria to the report to do my filtering but I ran into a problem when we needed to filter on the primary key for one of the tables but this primary key was not available in the crosstab query because including the key resulted in incorrect output from the crosstab query.

    I suspect that I could have adapted your example t work in my situation but I think I would developed a more complicated solution.

    Now my next major task will be to migrate the tables to SQL Server 2008. I just hope it doesn't break all my queries. I'm on a fence as far a using DAO or switching to ADO.

    Thanks and Regards,


    Tom Cyr

    A.D. Tejpal
    Tuesday, October 19, 2010 5:13 AM