Yeah, my current applications are doing exactly that, save monthly sales
data and merge for report into a cursor.
It works good because the report need only a few fields to be extracted.
But we are moving to MS SQL now.
But, what do you want to know?
Mine used to work like the following:
---
CREATE CURSOR sales_summary ( vendor c(3), style c(9), shop I, qty I)
FOR i = 0 TO tdate - fdate
m.dd = fdate + i
m.mfile = 'DATA\M'+LTRIM(STR(MONTH(m.dd)))+ LTRIM(STR(YEAR(m.dd),4))
IF FILE(m.mfile + ".DBF")
USE (m.mfile) IN 0 SHARED ALIAS sales
ELSE
* do error handling
ENDIF
INSERT INTO sales_summary ;
SELECT vendor, style, shop, sum(qty) FROM sales WHERE BETWEEN(sales.date,
fdate,tdate ) GROUP BY vendor, style, shop
USE IN sales
* This part could be written better. But it works just fine.
m.mm = MONTH(m.dd)
m.yy = YEAR(m.dd)
IF m.mm = 12
m.yy = m.yy + 1
m.mm = 1
ELSE
m.mm = m.mm + 1
ENDIF
m.dd = LTRIM( STR( m.mm, 2, 0)) + "/01/" + STR( m.yy, 4, 0)
m.dd = CTOD(m.dd)-1
i = m.dd - fdate
NEXT
---
On Wed, Apr 9, 2008 at 7:06 PM, Jeff Johnson <[EMAIL PROTECTED]> wrote:
> VFP tables work for me because they don't require a server like MSSQL
> Server or PostGreSQL or even Advantage. I can't install any server or
> programs where the data is stored. I use views and cursors that access
> the data on the network drive for the data file server. Reasonable size
> tables work fine, but tables over 30MB start to get unresponsive.
> Backing up the tables takes a considerable amount of time also.
> Splitting the tables seemed like a reasonable approach.
>
> Jeff
>
> Jeff Johnson
> [EMAIL PROTECTED]
> SanDC, Inc.
> 623-582-0323
> Fax 623-869-0675
>
> Paul M¢Nett wrote:
> > Kenneth Kixmoeller/fh wrote:
> >> On Apr 9, 2008, at 5:08 PM, Jeff Johnson wrote:
> >>> Has anyone built an application using this technique?
> >> I agree with Paul, but if you are running into size issues, one step
> >> short of going to a server-based DB (or as a stop-gap until you do)
> >> is to split the table vertically.
> >>
> >> I think splitting horizontally (by month or whatever) is generally a
> >> bad idea. Vertically isn't that great either, but it is far less
> >> disruptive to an old style VFP application that isn't set up for
> >> diverse data engines. Screens and reports can be hacked
> >> programmatically to accommodate the added table.
> >
> > Horizontal splitting makes sense sometimes, like when it is the same
> > data structure for x number of customers, where each customer only sees
> > their data. Better to have separate databases for each than to risk one
> > corruption spreading to everyone.
> >
> > Paul
>
>
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
