Also notice th INTO clause allows specifying a DATABASE to add the new table to and a long table name. Off topic: Long table names are obsolete as file names nowadays also can be long and not 8.3 DOS names only, but it's also good to know you can give DBFs an DBC internal name differing from the file name, if you ever come across someone else having done so and don't find files.
Also notice the VFP help covers many details about SQL in detail topics, eg this one:
When it comes to playing with data and finaly want to persist a cursor as a dfb file, I also prefer to create a file from a workarea already existing with COPY TO, not by doing one more query into table. COPY TO also allows to creae a free dbf, or a dbc dbf and it allows to decide whether or not to also create cdx files, which INTO TABLE won't do, so using INTO TABLE the new dbf has no indexes. For two reasons:
1. The query can combine whatever data of many source tables and thus existing indexes of them won't necessarily fit in other scenarios than SELECT * FROM singletable.
2. The newly created resultset is a dbf now without any index to be able to copy it.
In the general case workareea might come from CREATE CURSOR, using a view, queries INTO CURSOR with READWRITE clause and you can apply INDEX to it, so finally a COPY TO can copy the workarea indexes to a CDX file, too, while INTO TABLE only copies over data, as the resultset can't have any index yet, even when indexes where used to optimize the query.
And though Mike already began with it, let me end with restating the simplest way still is to copy data by copying files. On top of that the wish to copy data always points out to me you want a data extract and store it somewhere. Why? The main database is there as persinstence of all data. Making copies with certain conditions is creating data, which ages in comparison to original data. The usual way to go about data is only storing it non redundant in 4th normal form in one place, only redundancy allowed are backups, which are there for obvious reasons. But any data extract of months or years data can always be extracted from the original data. The only thing to store is the queries/conditions to be able to repeat the extraction process. I know it is very common to copy out data for export. There is a whole terminology about that, ETL - extract, transform, load, which illustrates an export and import into the next tool of a tool chain, mostly in data warehouseing or data mart as the general target database for an array of BI and other analyzing tools. But in regard to one database and application your main dbc should contain all data and wanting a months data means querying it from there.
Bye, Olaf.