POST Command

[Gregory Lypny]

Hi Dave,

	Thanks for responding.  Yes, I have checked the result function after 
the post, and it is always empty.  If I omit the CDML tag -Max=All from 
my post, I immediately get the default 25 records returned.  And 
curiously, when I transfer the database to my local Mac and post to 
localhost, as I mentioned, all records are, in fact, returned.

	Regards,

		Greg

	


On Friday, January 31, 2003, at 09:11  AM, 
metacard-request at lists.runrev.com wrote:

> Message: 12
> Date: Fri, 31 Jan 2003 14:05:29 +0000
> To: metacard at lists.runrev.com
> From: Dave Cragg <dcragg at lacscentre.co.uk>
> Subject: Re: POST Command
> Reply-To: metacard at lists.runrev.com
>
> At 8:28 am -0500 31/1/03, Gregory Lypny wrote:
>> Hello Everyone,
>>
>> 	I'm using the POST command to download records from an online
>> FileMaker database.  The problem I'm having is that no data is
>> returned in the variable *it* when I specify *all* (for finding all
>> records) in my url expression.  This doesn't happen with all my FM
>> databases, and I'm usually able to download all records, often in
>> the hundreds, without a glitch.  For the problem databases, I can
>> specify a specific number, say, ten, and it works; after that, 20
>> will work, then 30.  But won't return any data when I specify more
>> than 40 (and there are, in fact, about 150 records).  I'm guessing
>> that FileMaker delays returning any data if it has to do some
>> indexing first, MC then pulls down nothing, and the handler runs
>> through much more quickly then when there is data returned.
>>
>> 	Is there a command or setting I can use that will cause MC to
>> wait longer for FileMaker to respond?  I've tried to use
>> libUrlSetLogField to get more information but I'm not sure what I
>> should be looking for.
>
> Did you check the result function after the post command? This should
> give you a hint if the problem is on the server end.
>
> e.g
>
> post whatever to url whatever
> if the result is not empty then answer the result
>
> If the result is empty, then it looks like the problem is at the 
> client end.
>
> Before speculating on possible causes, can you confirm that the
> result is in fact empty?
>
> Cheers
> Dave