Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > Microsoft Office > Access and Access VBA > Access
Password Reminder
| FAQ | Members List | Search | Today's Posts | Mark Forums Read
Access Discussion of Microsoft Access database design and programming. See also the forums for Access ASP and Access VBA.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Access section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old March 30th, 2004, 11:09 PM
Registered User
Join Date: Mar 2004
Location: , , .
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default ADO Query kills the Wildcard in LIKE stmt

Hi all;

I'm working with VC++ OLEDB ADO connecting to an Access database, my problem is in the Query I have wildcards with a LIKE statement but either OLEDB is not passing wildcards or Access ignoring the wildcards in a LIKE statement.

This will work and find only exact part number input.
sprintf(szPartial, "SELECT * FROM [parts] WHERE [partno] LIKE '%s'", (LPCSTR)csInput);

This will NOT (added * to like statement) work and find NO part number matches from input.
sprintf(szPartial, "SELECT * FROM [parts] WHERE [partno] LIKE '%s*'", (LPCSTR)csInput);

I have viewed the "szPartial" string in the debugger and all the char's are there, there is no stripping of char's in the sprintf function.

Neither VC++ or OLEDB/Access kicks up a syntax error or any error at all they just seem to ignore any wildcards in the SQL statement.

Has anyone seen this kind of problem from OLEDB ADO?

Thanks in advance


Reply With Quote
  #2 (permalink)  
Old March 31st, 2004, 12:21 AM
Registered User
Join Date: Mar 2004
Location: , , .
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts

Hi All;

After much research and trial and error I think I have found the problem, it looks as though there was a change in the Wildcard syntax between Jet 3.51 and Jet 4.0. So if you use the datasource connection of "Provider=Microsoft.Jet.OLEDB.4.0;" you must use the SQL Server syntax for the wildcards (%_) and under "Provider=Microsoft.Jet.OLEDB.3.51;" you must use the "older" style wildcards (*?).

Hope this helps someone else...


Reply With Quote
  #3 (permalink)  
Old April 1st, 2004, 11:31 AM
Registered User
Join Date: Mar 2004
Location: Grand Rapids, Michigan, USA.
Posts: 4
Thanks: 0
Thanked 0 Times in 0 Posts

That is helpful. I have been trying to figure this out since I started using Access 2000. I switched back to using DAO when ever I needed to use LIKE because I was never getting any results. I will try the different syntax.

Thanks for the Info!!!
Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Internet Explorer kills my app !!! :0( _fluffy_ BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 2 October 17th, 2006 06:28 PM
Wildcard characters in query giving trouble programmer_kay ADO.NET 3 March 21st, 2004 10:04 PM
Expired CR9 session kills IIS darkov Crystal Reports 0 March 15th, 2004 05:28 AM
COUNT ON SELECT DISTINCT stmt savoym SQL Language 7 August 28th, 2003 07:58 AM
ADO Find using wildcard on an integer dfbosse VB How-To 2 June 26th, 2003 02:14 AM

All times are GMT -4. The time now is 05:37 AM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.