So I've never worked with SQL before, pretty much everything I know is from playing around with Access's Query Designer and then looking at the resulting SQL code. So I'm pretty sure that I'm not doing this efficiently.

Here's the skinny:

-I have a database called "SPC Data" that has measured data for each component on each circuit board that we build.

-I want to write one SQL query that will fetch around 500 rows based on combinations of barcodes and component data.

-The query is built dynamically in a VBA macro elsewhere, and this is what it looks like now:

```
SELECT *
FROM [SPC Data]
WHERE ((([SPC Data].Barcode)=1504803581) AND (([SPC Data].[Component ID]) Like '*R56')) OR 
((([SPC Data].Barcode)=1433700392) AND (([SPC Data].[Component ID]) Like '*C15')) OR 
((([SPC Data].Barcode)=1433700664) AND (([SPC Data].[Component ID]) Like '*R56')) OR 
((([SPC Data].Barcode)=1433700486) AND (([SPC Data].[Component ID]) Like '*R56')) OR
... about 220 more lines of criteria

```

I feel like this shouldn't be too memory-intensive, but Access complains that the Query is too Complex unless I pare the query down to only around 60 Or'd criteria (might work with more, this was just a random value that worked).

My question is this: why won't my SQL execute? Am I writing the SQL in a way that is making it inefficient and overly complex for Access? Is there a better way to select a bunch of matched pairs of criteria? Or should I just split it into multiple SQL queries, with ~60 criteria each? I'll be grateful for any direction on this.

**Update (1 hour later):** I still don't have a robust solution; Unions didn't help so I'm guessing this is an Access issue. I can try making a temporary table of the records I need and then joining it with the original to get all of my column data as DRapp suggested, or I could just split the SQL and import them 60 at a time. I was hoping there was some obvious mistake that I was making.