Using that data gives you a problem, but if you are scrupulous in use of that format (i.e. no variation from that format), you can still come out of this with your hide intact.
When you have a date in text as yyyymmdd format, you have to do TWO things.
First, use that DateAdd trick to subtract your ten weeks back in time.
Then use the Format function, perhaps as Format( the-date, "yyyymmdd" ), to create the text form of the date string.
If you have that text-oriented representation AND have separated out that date info from the rest of the longer string, a comparison of dates still works. It is a matter of assuring that you have an apples-to-apples comparison. If both dates are in the same text format it will work just fine. That is, you CAN test the string if you convert your target date to a string first. And if you do, you can even use a "table-date > target-date" type of expression, because that particular type of date string compares normally as long as the comparands are in the same format.
OR you can look at the column that converts things to dates. Again, dates compare correctly as long as they are all in the same format. HOWEVER, this bothers me:
CDate(Format([DataTestu];"0000-00-00"))
If you are reformatting the data, "0000-00-00" (first) isn't a date format and (second) your input isn't compatible with those formatting characters. Your input was extracted from a string so it is still a string, but the "0000" specification is used to generate output based on converting an integer to a digit string. What you have for input isn't a integer number. Its a text string composed of digits.
I'm not going to swear that CDate will like that. Personally, in this case I would do a text comparison and worry about reformatting that YYYYMMDD string separately.