I think you want MBRContains

I have an example from a previous post : Less restrictive query return less result due to simple removing one additional constraint

Give it a Try !!!

UPDATE 2013-05-08 17:05 EDT

You have this:

SELECT * 
FROM tb_gps 
WHERE MBRWITHIN(pt, MULTIPOINT(52.3641917981 4.87673850395, 52.3821782019 4.90619949605))

Put the MULTIPOINT in quotes

SELECT * 
FROM tb_gps 
WHERE MBRWITHIN(pt, 'MULTIPOINT(52.3641917981 4.87673850395, 52.3821782019 4.90619949605)')

I did this in my example

UPDATE 2013-05-08 17:39 EDT

If MULTIPOINT is not working for you, try using POLYGON

SELECT * 
FROM tb_gps 
WHERE
    IF(CONTAINS(GeoFromText('POLYGON(52.3641917981 4.87673850395,
    4.87673850395 4.90619949605,4.90619949605 52.3821782019,
    52.3821782019 52.3641917981)'pt),1,0)
;

You know something? It just dawned on me. You have the parameters backwards.

You have

SELECT * 
FROM tb_gps 
WHERE MBRWITHIN(pt,'MULTIPOINT(52.3641917981 4.87673850395, 52.3821782019 4.90619949605)')

Try reversing the parameters:

SELECT * 
FROM tb_gps 
WHERE MBRWITHIN('MULTIPOINT(52.3641917981 4.87673850395, 52.3821782019 4.90619949605)',pt)

Give it a Try !!!

As they stated 6 positions is all you need for Google maps - likely enough to not lose precision with a float. They may have correcting logic and likely don't have any mission critical apps running off standard API access (maybe??). Good answer concerning precision of coordinates here https://gis.stackexchange.com/questions/8650/how-to-measure-the-accuracy-of-latitude-and-longitude.

Decimal is a basic numeric field... your queries will be restricted to operations appropriate to decimals. This might be all you need if you're just storing the data and have an application layer that does any additional logic with the locations. If you're just appending Lat/Long to another table then you may already have all the indexing you need. For example, a Property table might include geo-coords, but it is primarily accessed by Property Name, Property Codes, etc. by users and systems. This should be simpler to read, maintain, and doesn't require any specific query/spatial knowledge.

If you want the benefits of GIS then you should store data in it's spatial specific data types. This will allow geospatial indexing, and direct, DB level manipulation of the coordinates. You can write queries that provide bounding boxes or calculate distances. This may be more efficiently handled at the DB level, especially for set selection. Instead of dumping a lot of unnecessary decimals to an app and expecting a mobile phone to do routing or distance calculations (as if decimals is all it would need!) you can use SQL spatial implementation to answer questions and find locations.

In SQL for spatial data you could create queries like this:

DECLARE @g geography = 'POINT(-121.626 47.8315)';
SELECT TOP(7) SpatialLocation.ToString(), City
FROM Person.Address
ORDER BY SpatialLocation.STDistance(@g);

To do the same with decimal points you would either need an API to feed that into or create your own logic to determine distance between lat/long pairs.

You can still get your spatial data out in the form of a lat/long numeric pair, but if that is all you're going to be using (e.g. feeding into an API) then just store it as a decimal.

DECLARE @g geometry;
SET @g = geometry::Parse('POINT(3 4 7 2.5)');


SELECT @g.STX; --3
SELECT @g.STY; --4
SELECT @g.Z; --7
SELECT @g.M; --2.5

The above code creates a point with the geometry data type and each SELECT returns the requested part of the point definition.