in reply to There are different LIKE wildcards between SQL implementations
in thread SQL Is Not Returning Any Records

All known SQL databases that i know of use % for wildcard matching. The difference in SQL on Access compared to the rest of the world is, that Access uses # around date and time types e.g. #03/14/2000#. Not like the rest of the known SQL world and treat them as strings like this '03/14/2000'.
  • Comment on RE: There are different LIKE wildcards between SQL implementations

Replies are listed 'Best First'.
RE: RE: There are different LIKE wildcards between SQL implementations
by Corion (Patriarch) on Jun 02, 2000 at 19:24 UTC

    From what I've heard about SQL dates, there is no rule as to how a date should be formatted (at least from my personal SQL guru, I've only heard different rantings about how different SQL servers (at different shops) interpret different strings as dates).

    Most notably, MS/Sybase SQL server seems to change the interpretation on what makes a string a date based on the locale settings for the server it is running on, but that might be the remains of some nightmare I've had :)

      We got all Horror Stories about SQL. Mine is sixteen tables in a dynamic query (the query looked different almost everytime) on MS SQLServer. For a reason unknown to me today I went for table number seventeen in the query. SQL Server said NO! It took half a day to find the server setting to increase the number of tables in SQL Server Query. When I was about to click the setting, I realize that I can take a few of the tables in the huge query and join them in a view. What a waste time! But I recognize the locale stuff. It can be annoying if sometime the locale is there and others the locale don't apply. And you end up doing a Trial-and-Error.
RE: RE: There are different LIKE wildcards between SQL implementations
by buzzcutbuddha (Chaplain) on Jun 02, 2000 at 19:21 UTC
    It gets even worse if you use both SQL Server and Access in the same shop, and you start
    linking tables, and you have to remember to modify your queries depending on where the
    table originates. Sometimes you get funky results if you don't.

    Can't wait to get out of here and into some consistency.