MSSQL: Unknown Version - HELP!

[Sean D. McCluskey]

Hi All!

I am pasting this message from another person who is having the same trouble
that I am. Does anybody have any advice that may help me?

-Sean

I have set up an alias for an MSSQL database. In SQL Explorer (D3) the
database type comes up as "MSSQL: Unknown Version: Mapping error: Bad
template: SQL Server [^0-9]*([0-9]+)\." Entering a SQL string works fine,
and I can access the database fine using the alias
(so far as I can see) but it has made the explorer useless.

What have I done? How do I fix it?

Thanks in advance.

[Alain Quesnel]

What version of MSSQL are you using? For 7 and above, I would suggest using
Adonis:

www.cybermagic.co.nz/adonis/

--

Alain Quesnel
ci...@compuserve.com

"Sean D. McCluskey" <SDMcC...@mcoa.com> wrote in message
news:3ca86f7b$1_1@dnews...

[Jim Elden]

Alain,

Is Adonis faster than the ADO components that come with D6?

Tx,
--
Jim

[Sean D. McCluskey]

1) SQL 2000
2) What is that?

"Alain Quesnel" <cinqsa...@compuserve.com> wrote in message
news:3ca87955_1@dnews...

[Alain Quesnel]

No idea. I suggested Adonis because he seems to be using D3. I've used D6's
ADOExpress (or dbGo as the Borland marketing dept. calls it) with MSSQL 7
and 2000 and I was happy with the performance (low volume though).

--

Alain Quesnel
ci...@compuserve.com

"Jim Elden" <x@yz> wrote in message news:3ca87f48_2@dnews...

[Alain Quesnel]

Adonis is a set of components for D3, 4, 5 & 6. It allows you to connect to
an ADO data source (MSSQL, Access, Oracle, etc.) using Microsoft's ADO
technology.

A) I suggested Adonis because you seem to be using D3. If you have D5 and
above, you could use ADOExpress which comes with Delphi (add-on for D5 Pro)
B) ADO is the preferred way of connecting with MSSQL, especially MSSQL 2000.
The BDE was not updated for MSSQL 7 and up. Had to do with a Microsoft dll
that Microsoft did not update (DBLib.dll or something).

--

Alain Quesnel
ci...@compuserve.com

"Sean D. McCluskey" <SDMcC...@mcoa.com> wrote in message

news:3ca89f09$1_1@dnews...

[Sean D. McCluskey]

Alain,

Thanks for your input. I am using D6. We are migrating a large medical
management application that we sell from Advantage Database Server to SQL
Server 2000. The current application uses the SetRange method to limit
records, (All OVER THE PLACE!). Because of this, we decided to use the DBE
to connect to SQL 2000. Will this cause us problems? Is Borland ever
planning to offer full BDE support for SQL 2000? I am hoping that we can
use the BDE.

Thanks,

-Sean

P.S. - Any input would be greatly appreciated!

"Alain Quesnel" <cinqsa...@compuserve.com> wrote in message

news:3ca8b891_2@dnews...

[Aage Johansen]

"Sean D. McCluskey" wrote:
> ...
> ... Because of this, we decided to use the DBE

> to connect to SQL 2000. Will this cause us problems? Is Borland ever
> planning to offer full BDE support for SQL 2000? I am hoping that we can
> use the BDE.

A lot of people will be VERY surprised if full BDE support for SQL2k
would ever be offered. Think of "avoiding the BDE" as a goal :-)
Even more important: using TTables with C/S databases is not a good
thing.

Regards,
Aage J.

[Kevin Frevert]

Sean,

Microsoft didn't update their DBLib (which the BDE uses) for MSSQL
7.0/2000. If you don't plan on using the newer datatypes introduced in
7.0, then the BDE should work fine.

Here is an excellent article by Wayne N of TeamB...

=================================================
TTables vs. TQuerys

The whole reason there is both a TTable and a TQuery component is due to the
fact there table-oriented databases like Dbase, Paradox, or Access, and
there are set-oriented databases like Interbase, Oracle, and MSSQL. These
different types of database systems work and behave completely different
from one another and the same methods of access cannot be equally applied.

TTable is specifically designed to work best with table-oriented systems -
it is "native" to them. Using a TQuery against such databases is slower
because they do not understand SQL and so the BDE must interpret the SQL and
convert it to table calls for that database.

TQuery is specifically designed to work best with set-oriented databases
that understand SQL directly and were designed to work this way. Using a
TTable against such a system is slower because the BDE must convert the
table functions into SQL instructions to be sent off to the database.

Some of the things that TTables do that eat time and resources over a
network with an SQL system are:
- on Opening, always sends many queries to the database to get all the
metadata for all fields and indexes in the selected table in order to
provide you with a selection of these (only *Live* TQuerys do this).
- if you have large records with many fields, TTable will always select ALL
fields even if you only want one or two. This is especially bad if the table
contains blobs and you do not need them.
- Using Locate or FindKey or RecordCount forces all records to be fetched
because such searching / counting has to be done on the client side. This
can be eased by using a good filter (in the Filter property, not the
OnFilter event) to limit the records that need to be fetched (Filters are
turned into SQL where clauses by the BDE).
- if used in a grid, TTable must frequently execute multiple queries to fill
the grid whenever you change record positions.
- Tables prevent you from using the power of SQL when working against a real
SQL server - they only see physical tables (or views in SQL systems),
whereas you can write TQueries to slect any raltionships between and number
of tables and get only *exactly* the data you need.

With TQuerys, you still need to use them right to get the most out of them,
but the point is that you *can* use them right with regard to SQL databases.
- with the exception of extremely small "lookup" type tables (e.g. State
codes) *always* use where clauses to limit the number of records brought
back, if you do not then you are defeating the whole purpose of using them.
- unless you *really* need to every field in a table, always specify the
fields you actually need (e.g. "select cust_id, cust_name from...", not
"select * from..."). A tip here is to avoid editing records in a grid, use
grids only for selection. This allows you to only select the minimum fields
needed for selection, then use another query to select all fields for that
ONE selected record for editing purposes.
- Never use the Filter property or OnFilter event, or call RecordCount with
a TQuery, this forces the entire record set to be fetched. If you really
need the record count, use another query to get it so the server will do the
counting and send back the count itself instead of all the records.

--
Wayne Niddery (WinWright Inc.)
RADBooks - http://members.home.net/wniddery/
I love deadlines. I like the whooshing sound they make as they pass by -
Douglas Adams

-------------------------------------------------

Good luck,
krf

Sean D. McCluskey <SDMcC...@mcoa.com> wrote in message

news:3cab6467$1_1@dnews...

[Nick Pavlina]

SetRange should work just fine with the BDE & MSSQL 2000. In fact, they
work pretty much like a TQuery with a WHERE clause with the fields you
specify range for. LOCATE works much the same way, but be careful of the
searchOptions.
However, you are likely to run into other data migration problems:
- NULLs are not allowed in Index Fields
- Object Names may be case-sensitive (FieldNames used in SetRange for
example.)

I agree with those that recommend moving away from the BDE, but I also
know that's not always the best choice with legacy code. In fact, if
you're doing a lot of sequential (old batch style) processing, TTable has
some performance benefits resulting from it's internal buffering. Of
course, this is a negative for interactive processing! <g>

"Sean D. McCluskey" <SDMcC...@mcoa.com> wrote in

news:3cab6467$1_1@dnews:

[Sean D. McCluskey]

Even more important: using TTables with C/S databases is not a good
thing.

Why is that???

-Sean

"Aage Johansen" <aagj...@offline.no> wrote in message
news:3CAB6EA8...@offline.no...