0

How do I make this a select statement? This is for Microsoft access. I want it to look everywhere and in any part of any cell in an entire table and find "Coal 104" and replace it with "Lava 104"

Will Fix
  • 105
  • 1
  • 4
  • 16

3 Answers3

1

Off the top of my head.

Update myTable SET cell1 = Replace(cell1, 'Coal 104', 'Lava 104'), -- repeat for all cells in table
-- optional, but may run faster
WHERE cell1 LIKE '*Coal 104*' OR -- repeat for all cells in table

In case it is necessary to say, only do this to the VARCHAR fields.

Matthew Vines
  • 27,253
  • 7
  • 76
  • 97
  • Unless the UPDATE is executed in SQL92 mode, use \* (instead of %) as the wildcard character. – HansUp Nov 03 '10 at 19:19
  • That LIKE pattern will force a full table scan, so the WHERE clause is unlikely to speed up the operation. – HansUp Nov 03 '10 at 19:21
  • @HansUp - thanks for the syntax correction, I don't spend a lot of time in Access. That's why I put it as a maybe, I would have to run it both ways to see, and as this appears to be a one off operation, it probably isn't worth the extra typing. – Matthew Vines Nov 03 '10 at 19:21
  • @Matthew Usually the wildcard gotcha is reversed ... someone tries `LIKE '*Coal 104*'` with an ADO connection and doesn't get anything to match. ADO always operates in SQL92 mode, so requires the ANSI style wildcards. – HansUp Nov 03 '10 at 19:30
  • 1
    @HansUp: you can use `ALIKE '%Coal 104%'` regardless of Query Mode (ADO, DAO, whatever). – onedaywhen Nov 03 '10 at 21:25
  • @onedaywhen You surprised me! I thought you were the one [daywhen] who advised against ALike because it's not portable to other databases. – HansUp Nov 03 '10 at 21:29
  • @HansUp: I've being recommending `ALIKE` literally for years (e.g. this from 2006: https://groups.google.com/group/microsoft.public.access/msg/2c220d2e6c5fdaa5?hl=en) and I can find many times I've recommended it on SO too. The main problem with `ALIKE` is that it isn't officially supported (but I don't think it's actually too much of a problem). If I did say `ALIKE` isn't portable then that would have been a misstatement: you merely need to replace `ALIKE` with `LIKE` to be SQL-92 compliant. – onedaywhen Nov 03 '10 at 21:59
  • @HansUp: ...and if you can cite where I made the misstatement on SO I'll happily correct it :) – onedaywhen Nov 03 '10 at 22:00
  • @onedaywhen Clearly I mis-remembered. Sorry about that. Stuff happens when you get old. I use ALike, too. RE portability, I concluded it will be easier on me to track down and change ALike to Like instead of tracking down \* and ? and changing them to % and _. – HansUp Nov 03 '10 at 22:12
  • @HansUp: actually, I think you did remember correct: this answer (http://stackoverflow.com/questions/719115/microsoft-jet-wildcards-asterisk-or-percentage-sign/720896#720896) which I have now edited to emphasise that `ALIKE` is highly portable (in exactly the way you say here). Thanks for the spot :) – onedaywhen Nov 03 '10 at 22:15
  • @onedaywhen Thanks. Good to know I'm not as senile as I feared. Cheers. – HansUp Nov 03 '10 at 22:23
  • It's not in Google Groups yet, but I posted today in comp.databases.ms-access on SQL 92 mode and problems I kist encountered. Did you know that if you turn it on in a database in which you've used the standard Access wildcards, all the LIKEs in saved SQL statements (QueryDefs, Recordsources, Rowsources) get changed to ALIKE? This rather makes me think that it's pretty much supported if Access itself is editing your SQL statements to make them compatible with the changed mode. And also did y'all realize that the list of reserved words is completely different in SQL 92 mode than in SQL 89 mode? – David-W-Fenton Nov 05 '10 at 23:19
  • My conclusion is that I will never use SQL 92 mode, ever, as it's simply not applicable to my work, which has no need whatsoever for a SQL dialect that is foreign to Access/Jet/ACE. I'm sure @onedaywhen will disagree, but I can't think of how you'd make a case for it's utility (the DDL issue is an artificial problem that MS should rectify by bringing DAO into parity with ADO). – David-W-Fenton Nov 05 '10 at 23:22
  • @David-W-Fenton "I'm sure @onedaywhen will disagree" -- I disagree that it's a "dialect that is foreign to Access/Jet/ACE"; after all, ANSI-92 Query Mode syntax doesn't work on any product. I also disagree that it is not applicable to your work: I think you need to be aware that someone could connect to your mdb (or whatever) using ADO and your `*` wildcards no longer behave as you intended e.g. your Validation Rules fail to prevent invalid data, your queries expose more data than they should etc. – onedaywhen Nov 06 '10 at 09:55
  • @David-W-Fenton: "the DDL issue is an artificial problem that MS should rectify by bringing DAO into parity with ADO" -- I agree :) – onedaywhen Nov 06 '10 at 09:58
  • How am I responsible for somebody connecting to the data store for one of my apps and using the wrong syntax/data interface? This looks like a classic NOT MY PROBLEM to me. If somebody doesn't know how to interface with Jet/ACE reliably, then I'm not really responsible for that. I'm pretty sparse with validation rules, actually, and don't know that I've ever used a wildcard in one, in any case. – David-W-Fenton Nov 07 '10 at 04:01
1

You could do it with VBA code. You'd need to iterate through all the tables in your database, and for each table, iterate through all the fields.

With each field, create a sql statement to update the rows containing your search value and replace it with your target value. Then execute your dynamic sql statement.

Beth
  • 9,531
  • 1
  • 24
  • 43
  • Could also check each field Type so as to avoid attempting the text replacement for a numeric field. – HansUp Nov 03 '10 at 19:33
  • yes, @HansUp. He said he wanted to look everywhere, so that's the approach I gave him. – Beth Nov 03 '10 at 19:48
0

Since it is not entirely clear if you want to update the values in the table or if it is ok to just show the new values I elaborate (this might even be useful to better understand the process).

This is the table 'mytable' containing the input values in cell1

**cell1**
abc Coal 104 efg
abcdefg
othervalue
Coal 104 xyz
more

If you use the graphical query editor in MS Access to show all the values (no replace yet) Access would create the following SQL-stamtement (right click in the editor window an select 'SQL-View'):

SELECT myTable.cell1
FROM myTable;

(nothing special really) Now going back to the graphical editor window you could could insert a second value, e.g. cell1_new that shows the replaced value (this might be useful for 'debugging' in any case) and you get (again in the SQL-view)

SELECT myTable.cell1, Replace([cell1],"Coal 104","Lava 104") AS cell1_new
FROM myTable;

runnig the query I see:

**cell1**          **cell1_new**
abc Coal 104 efg     abc Lava 104 efg
abcdefg              abcdefg
othervalue           othervalue
Coal 104 xyz         Lava 104 xyz
more                 more

(just to be clear, this does not update the values in the original table, it is just a view).

Using the graphical query editor you can even construct UPDATE-queries. First change the query-type to 'Update query' (i am not sure that is what it is called in English MS Access). Secondly insert your replace-'formula' that was used to show the values for 'cell1_new' to the line Update just below cell1 an myTable (without the 'cell1_new:'). Delete the formula for this column cell1_new (as we now Update only the values in column cell1) Third, as it was suggested you could restrict the values that get updated to only the lines that contain "Coal 104", so enter "Coal 104" in the criteria-line.

In the grafical editor it should look more or less like this:

Field  cell1
Table  myTable Update
Replace([cell1],"Coal 104","Lava 104")
crieteria Like "*Coal 104*"

Again checking the SQL-Statement (which I find easier to understand than the grafical view) now read like this:

UPDATE myTable SET myTable.cell1 = Replace([cell1],"Coal 104","Lava 104")
WHERE (((myTable.cell1) Like "*Coal 104*"));

(I left those annoying brakets in the WHERE-Statement Access puts in so it looks the same).

To finish, run this query (e.g. press the exclamation mark). Normally (except you changed this behavior in settings) Access asks you if you really want to update -- in this example -- two values.

I hope this helps to get an idea, how to use the grafical editor to experiment with different queries. I think in that respect Access is not a bad learning tool.

HTH Andreas

Andreas J
  • 526
  • 4
  • 18