>>That, or check for 1900-01-01 in the cursors and blank those values. That will change the update status on those records, but then there's a trick - you set the cursor to non-updatable, do a tableupdate(), change back to updatable. Easy to do if you're using a cursoradapter.
>
>I can see that working for something with just one record or a few - but when doing reporting, this app has date fields that also work like a flag e.g. field Funding_Date not only gives the date of funding for their product but if it is empty, it means the product has not been funded yet. Where it comes into play on reports is running a report of unfunded files e.g. WHERE EMPTY(Funding_Date); so would I have to bring down the whole table first, nuke the Funding_Date for empty dates and then run another query against the local cursor? Or I guess re-reading your answer, I would have to put in AND Funding_Date # {^1990-01-01}?

Since SQL doesn't have date literals, it uses strings... and the approach I use is

... and funding_date > '1910-01-01'

Note that you used fox SQL syntax and I'm replying in TSQL syntax. The reason is that I pick the records I want in the where clause of the cursor I'm bringing down, rather than bring more down and filter fox-side. The fewer bytes you push over the wire, the better. Sometimes, for large reporting queries, with lots of repeated values from lookups, I bring the lookups separately and then join the cursors in fox - far faster.

>>That's the limit on string value in a variable (perhaps not even there, but many string functions may chop it) but not on a memo field. You can still do strtofile() and filetostr() straight with a memo field. I saw it work for a few hundred megabytes.
>
>I think someone did point out that StrToFile()/FileToStr() can handle larger strings - in this case, the string has to be run through STRCONV() because of encoding and STREXTRACT() to pull out data between tags so from what I can tell, we are bumping up against 16MB limits once we get to those other functions. Mind you, if I rewrote the entire app myself to do a away with it going through this document app, maybe I would not need any of that.

>I looked at the Postegresql docs on data types - do you know is there really any difference between varchar and text?

With varchar you can specify the length, and it's stored inside the table. Text is a memo, and stored elsewhere, so it's a bit of a performance hit.