TTABLE routines for Setting ranges do not work.

Quote
On Fri, 16 Feb 1996 00:44:48 GMT, ga...@athenon.com (Garry Freemyer) wrote:
>I have a tttable componant Salestable and I wish to limit the range of
>visible records using SetRangeBegin, SetRangeEnd and ApplyRange. I set
>it up EXACTLY as in the example in the online help except I used a
>date field as my range criteria. The instant I execute applyrange all
>my dbedit cotrols go blank and all the buttons on the dbnavigator
>except post, delete, add and edit are dimmed!

>When I try to move to the first record and retrieve the date of the
>first valid record using salestable.first with an indexname of
>'DateClosed' the function
>salestable.fieldByName('DateClosed').AsDateTime returns a blank
>possibly nul. Then when I run salestable.last and attempt to read the
>date of the last record it reads the latest record in the entire
>database as if the range hasn't been applied. Then when I try to run a
>report unit that disables and enables the controls  the dbedits
>suddenly fill in and yet I see all the records not just the ones I
>want!!!

You did not supply enough information to make an intelligent guess as to
what might be failing. What is the table type? SQL, Paradox, dBASE? What
fields comprise the index used for the range filtering and in what order?
Did you change the IndexName property between setting the range and viewing
the data? Are there records in the table with blank dates in the range
field? Is the date field a TDateField or a TDateTime field? Can you post
what code you were using to set the range?

(All follow-ups to the newsgroup only, please.)

Quote
>Whats going on here? I hate to keep re-inventing the wheel but I have
>wasted at least 25 hours writing code to take advantage of sql or
>other routines such as this only to have to throw the code away as
>trash and spend even more time re-inventing the wheel. I cannot charge
>for those wasted hours and I really would like to purchase the new
>upgrade but all these horrible surprises I keep running into are
>making it so bad for me that I can hardly pay the rent!!! Its really
>annoying!!!

>Some of the surprises that have costed me many hours is the fact that
>I cannot order by and edit records using an sql componant,...

Not all queries will return read-only data sets. You can use an ORDER BY
clause in an SQL query and still get an editable result set. Other factors
are likely causing your read-only set.

Quote
>...There is mention of using a separate query component to make an update
>statement but no example of just how to do this so that cost me 20
>hours of lost time alone PLUS another 20 hours of lost spare time!!!...

The section of the Database Application Developer's Guide you cite refers
to creating a parameterized query that uses the parameter(s) and a WHERE
clause to find the right rows in the table (based on the current record in
the read-only TQuery), and an UPDATE command to actually effect the column
value changes. Using a parameterized query is described starting on the
facing page, in the section "Dynamic SQL statements."

Basically, if Query1 will return a read-only result set, Query2 can be used
to effect the changes needed. The DataSource property of Query2 would be
set to the TDataSource connected to Query1 (say, DataSource1). The WHERE
clause in Query2 would include one or more parameters so that only the
correct rows will be affected by the UPDATE command. The parameters would
be named the same as column names in the table. The combination of setting
the DataSource property and naming the parameters this way results in the
parameters automatically being defined and populated with data at run-time.
For instance, if the key column in Query1 were ACCOUNT, the SQL in Query2
might look something like:

  UPDATE MYTABLE
  SET AMOUNT = 200, DATE_IN = DATE
  WHERE ACCOUNT = :account

Quote
>...I am weeks behind and I cannot afford to spend another week surfing the
>web for answers so I guess I will re-invent the wheel yet again and do
>it all the hard way by writing my own code. Another surprise is that
>the BDE only allows the first 16 fields of a database to be a key
>field and the IndexByName property insists on only using existing
>field names and will not accept secondary indexnames DESPITE what
>borland said.

The TTable component has two index-related properties: IndexFieldNames and
IndexName. The IndexFieldNames property can only be populated with actual
column names from the table, index names are not accepted. The IndexName
property must be either blank or contain the name of a single existing
index. If this property is left blank, the primary index is the active
index (if one exists). If an index name is placed in the property, that
secondary index becomes the actively ordering index.

If you are having trouble with the IndexName property accepting a validname
of an existing secondary index, it is an exception. Could not say what
might be causing that, but have never heard of nor seen it myself. Try
adding a TTable component in an otherwise empty form in a new project.
Connect the TTable to this table and, in the Object Inspector, see if the
IndexName property lists existing indexes.

Quote
>Thanks to any kind soul that can save me from this Delphi purgatory
>and help me get the setrange methods working as advertized before I
>have to throw away another 16 hours of code!

**************************************************************************
Steve Koterski                  "Results! Why, man, I have gotten a lot of
Product Group Manager           results. I know several thousand things
Delphi Technical Support        that won't work."
Borland International, Inc.                    -- Thomas Edison, 1847-1931