Board index » delphi » Delphi 5, SQL, Dbase 3 files, Same SQL Stmt, different results on different machines.

Delphi 5, SQL, Dbase 3 files, Same SQL Stmt, different results on different machines.

Same SQL statement produces different results on same data across NT
network.

It seams link the machine is affecting the Select Statement.

The select statement is: Select * from  Projmast.dbf p where p.status='6'

On one machine it produces the correct results and on another machine,
records are missing from the results.

Any Ideas.

--
Tony Nasca
Dove Net Technologies
3901 Peppertree Lane
Silver Spring, MD 20906
Phone: 301-460-6842
Fax: 301-460-6154
E-Mail Na...@DoveNet.com
Web: http://www.dovenet.com
Downloads: http://www.dovenet.com/downloads

 

Re:Delphi 5, SQL, Dbase 3 files, Same SQL Stmt, different results on different machines.


On Wed, 12 Apr 2000 14:00:50 -0400, "Tony Nasca" <na...@dovenet.com>
wrote:

Quote
>Same SQL statement produces different results on same data across NT
>network.

>It seams link the machine is affecting the Select Statement.

>The select statement is: Select * from  Projmast.dbf p where p.status='6'

>On one machine it produces the correct results and on another machine,
>records are missing from the results.

Hmm. What is the table level for that dBASE table? What is the actual
data type for that Status column? NUMERIC or true INTEGER? I wonder
whether the column is NUMERIC and what you are seeing is the odd
handling of floating point numbers of some computers.

Try the statement this way, forcing the Status column to be treated as
a SMALLINT.

  SELECT *
  FROM "Projmast.dbf" p
  WHERE CAST(p.status AS SMALLINT) = 6

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\
Steve Koterski                    "If you aren't fired with
Technical Publications            enthusiasm, you will be
Borland                           fired with enthusiasm."
                              -- Vince Lombardi (1913-1970)

Re:Delphi 5, SQL, Dbase 3 files, Same SQL Stmt, different results on different machines.


Good Try, but Status is a String field, 1 Character wide.

This problem is also occurring in other areas of the program but all related
to SQL statements. On x number of machines within the system, the results
are correct but on some machines the results are correct.

Here is another example of a statement that intermittently works.

Select * from Stock.dbf s  where ((s.instock < s.MINQTY) and (s.MINQTY<>0));

In the above case, on the machine that works, you get x records. On the
machine that fails, you get 0 records.

Thanks for the response, any ideas.

Tony

P.S., I will remember the "WHERE CAST(p.status AS SMALLINT) = 6" ideas for
future use.

Quote
<skoter...@NOSPAMborland.com> wrote in message

news:vpm9fs8t6t8t6jfb9nve340vk9h8p2d4k5@4ax.com...
Quote
> On Wed, 12 Apr 2000 14:00:50 -0400, "Tony Nasca" <na...@dovenet.com>
> wrote:

> >Same SQL statement produces different results on same data across NT
> >network.

> >It seams link the machine is affecting the Select Statement.

> >The select statement is: Select * from  Projmast.dbf p where p.status='6'

> >On one machine it produces the correct results and on another machine,
> >records are missing from the results.

> Hmm. What is the table level for that dBASE table? What is the actual
> data type for that Status column? NUMERIC or true INTEGER? I wonder
> whether the column is NUMERIC and what you are seeing is the odd
> handling of floating point numbers of some computers.

> Try the statement this way, forcing the Status column to be treated as
> a SMALLINT.

>   SELECT *
>   FROM "Projmast.dbf" p
>   WHERE CAST(p.status AS SMALLINT) = 6

> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\
> Steve Koterski                    "If you aren't fired with
> Technical Publications            enthusiasm, you will be
> Borland                           fired with enthusiasm."
>                               -- Vince Lombardi (1913-1970)

Other Threads