I have a commercial, off-the-shelf application that stores it's data in DBISAM (V3, if I remember correctly). I want to report out of the databases
using MS SQL Server Reporting Services.

We purchased the ODBC driver and I installed it and configured an ODBC data source on my SQL Server box and set up a linked server.

I'm finding that a SELECT * from my tables doesn't always return all the rows, I first suspected this when I saw rows in my COTS application
which were not represented on my reports. A quick compare of the results of SELECT COUNT(*) and SELECT * confirmed my suspicions. The
COUNT(*) shows a higher number.

If I use the COTS app to determine a missing row and write a SELECT on the SQL side with the appropriate WHERE clause to bring back only that
row, it works fine, so it would seem that the ODBC driver can access all the rows just fine.

Any ideas how I might solve this problem? I'm suspecting a corrupt primary index, but don't know how to fix without developer tools. Is there a
command I can issue via ODBC to rebuild the index? Or am I off base entirely on this?

TIA,

Ray

"Ray Williams" <rwwilliams@dickies.com> wrote in message
news:E5CFAEF9-FE37-44D2-B561-2ACE78882D22@news.elevatesoft.com...
>
> Any ideas how I might solve this problem? I'm suspecting a corrupt primary
> index, but don't know how to fix without developer tools. Is there a
> command I can issue via ODBC to rebuild the index? Or am I off base
> entirely on this?
>


Get the DBSYS utility from Elevate, it will let you look at the raw data and
rebuild inexes if necessary. Login with your customer name and password, the
program you need is in the DBISAM Additional Software and Utilities.

Robert

Ray,

<< I'm finding that a SELECT * from my tables doesn't always return all the
rows, I first suspected this when I saw rows in my COTS application which
were not represented on my reports. A quick compare of the results of SELECT
COUNT(*) and SELECT * confirmed my suspicions. The COUNT(*) shows a higher
number.

If I use the COTS app to determine a missing row and write a SELECT on the
SQL side with the appropriate WHERE clause to bring back only that row, it
works fine, so it would seem that the ODBC driver can access all the rows
just fine.

Any ideas how I might solve this problem? I'm suspecting a corrupt primary
index, but don't know how to fix without developer tools. Is there a command
I can issue via ODBC to rebuild the index? Or am I off base entirely on
this? >>

It could be a corrupt index.  As Robert indicated, using the DBSYS utility
(DBISAM Additional Software and Utilities download from the
Customers/Download Products area) to repair the table (Utilities/Repair)
will indicate if any corruption is present.  You might want to select the
Force Index Rebuild option also.

If that doesn't work, we can look into this further.  There may be an issue
with the fetching that is causing some of the rows to get skipped.

--
Tim Young
Elevate Software
www.elevatesoft.com

>>It could be a corrupt index.  As Robert indicated, using the DBSYS utility
(DBISAM Additional Software and Utilities download from the
Customers/Download Products area) to repair the table (Utilities/Repair)
will indicate if any corruption is present.  You might want to select the
Force Index Rebuild option also.>>


I'll give it a try next time I'm at this site and report back.

Thanks,

Ray Williams

"Tim Young [Elevate Software]" wrote:
<<
It could be a corrupt index.  As Robert indicated, using the DBSYS utility
(DBISAM Additional Software and Utilities download from the
Customers/Download Products area) to repair the table (Utilities/Repair)
will indicate if any corruption is present.  You might want to select the
Force Index Rebuild option also.
>>

No luck with the DBSYS utility, but I did find a solution.

A little background first...
ServerA is my SQL box, but my DBISAM files are on ServerB. I had installed the DBISAM server on ServerA and was using it to access the files
on ServerB.

I shut down the DBISAM server and changed my SQL data source to use the ODBC driver to access the remote files directly and now they return
all rows.

Thanks for the help.

Ray

Ray,

<< I shut down the DBISAM server and changed my SQL data source to use the
ODBC driver to access the remote files directly and now they return all
rows. >>

So, just to confirm:  it worked for direct access to the tables, but not
with a remote connection to the DBISAM Database Server ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com