Board index » delphi » BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem

BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem

Using Delphi 3.02 C/S, BDE 5.0, ODBC 3.5, and SQL Server 6.5.

A parameterized query of the form

select * from cncuser.tbldia where
diatblname = :diatblname

This works against a Paradox and Access table.  It works with BDE  4/5 and
ODBC 3.0x against a SQL Server database.  The problem occurs using the
latest ODBC 3.5 with BDE 4 or 5.

Monitored SQL with BDE 4/5 and ODBC 3.0x

1       17:39:17  SQL Prepare: SQL Server - select * from cncuser.tbldia
where diatblname=?
2       17:39:17  SQL Data In: SQL Server - Param = 1, Name = , Type =
fldZSTRING, Precision = 5, Scale = 0, Data = craig
3       17:39:17  SQL Execute: SQL Server - select * from cncuser.tbldia
where diatblname=?

Monitored SQL with BDE 4/5 and ODBC 3.5

1       18:45:24  SQL Prepare: SQL Server - select * from cncuser.tbldia
where diatblname = ?
2       18:45:24  SQL Data In: SQL Server - Rows affected = 0
3       18:45:24  SQL Stmt: SQL Server - Close

The BDE didn't supply the parameter data!!!!.   You get an error -
"Operation Not Applicable".

If you define a System DSN in the ODBC, both BDE4 and BDE5 will pull this
info in automatically and create an alias of the same name as the System
DSN.  This uses the BDE "SQL Server" database driver.

In BDE4, you could create an alias using the MSSQL database driver and
connect directly to the SQL server without defining anything in the ODBC.

In BDE5, the MSSQL driver is gone - there is no direct connection to the SQL
Server.  There is a SQL Server database driver, but this must be used in
conjunction with an ODBC DSN.

The question is - is this a setup problem or a real problem?  Is there a
work-around?  With BDE4/5 using ODBC, what makes it{*word*222}up with ODBC 3.5.

Any comments or help would be greatly appreciated.

- Craig

 

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


Quote
>The question is - is this a setup problem or a real problem?  Is there a
>work-around?  With BDE4/5 using ODBC, what makes it{*word*222}up with ODBC 3.5.

>Any comments or help would be greatly appreciated.

>- Craig

Craig and Scott,

When 3.02 came out and the new BDE version came on the scene, I noticed
quite a few people experienced similar problems...

Being an anal-boy<g>, I decided to wait and stick with 3.01, and the 4.00
BDE..

I am running the ODBC driver that came with MS SQL (actually now that I
think about it, I wonder if my Office97 install updated it...???)
ODBC 2.65.0213 and everything works ducky still (hence my hesitation to
move<g>)
(parm queries AND Transactions - against MS SQL Server)

Hope this helps,
--Raymond
If replying via e-mail, remove the NS in the return address...

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


You are the first to confirm my own problem.  This is the 3.5 ODBC SQL
Server driver at fault.  I changed the driver back to 2.65 and found that it
worked fine but had problems with transactions.  Try backing up your
SQLSVR32.DLL file in your System32 or (Win95 - System) directory and copying
the v2.65 driver across from another PC.  You will have the params working
but you may have other problems with transactions.  Eg. BEGIN and COMMIT,
etc.  then again, maybe not...

I have to use ODBC because the upgrade to D4 C/S was unbelievable and it had
too much of the stuff we don't need.  Overkill really.  So now I am stuck
with using the ODBC SQL Server driver that is {*word*81}ed.

If you have any luck or anyone else out there then please let us know.  Same
goes here.

Thanx

Scott Ritter
<rit...@bblfm.com.au>
DBA - Analyst/Programmer
BBL Funds Management Limited

Quote
Craig M. Pulford wrote in message <6qqi5p$2h...@forums.borland.com>...
>Using Delphi 3.02 C/S, BDE 5.0, ODBC 3.5, and SQL Server 6.5.

>A parameterized query of the form

>select * from cncuser.tbldia where
>diatblname = :diatblname

snip

Quote

>The BDE didn't supply the parameter data!!!!.   You get an error -
>"Operation Not Applicable".

snip
Quote
>The question is - is this a setup problem or a real problem?  Is there a
>work-around?  With BDE4/5 using ODBC, what makes it{*word*222}up with ODBC 3.5.

>Any comments or help would be greatly appreciated.

>- Craig

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


Just tried something similar I have an MSSQL driver with BDE 5 .....
looks like setup to me

Terry Murphy

On Tue, 11 Aug 1998 18:53:21 -0400, "Craig M. Pulford"

Quote
<c...@uComDesign.com> wrote:
>Using Delphi 3.02 C/S, BDE 5.0, ODBC 3.5, and SQL Server 6.5.

>A parameterized query of the form

>select * from cncuser.tbldia where
>diatblname = :diatblname

>This works against a Paradox and Access table.  It works with BDE  4/5 and
>ODBC 3.0x against a SQL Server database.  The problem occurs using the
>latest ODBC 3.5 with BDE 4 or 5.

>Monitored SQL with BDE 4/5 and ODBC 3.0x

>1       17:39:17  SQL Prepare: SQL Server - select * from cncuser.tbldia
>where diatblname=?
>2       17:39:17  SQL Data In: SQL Server - Param = 1, Name = , Type =
>fldZSTRING, Precision = 5, Scale = 0, Data = craig
>3       17:39:17  SQL Execute: SQL Server - select * from cncuser.tbldia
>where diatblname=?

>Monitored SQL with BDE 4/5 and ODBC 3.5

>1       18:45:24  SQL Prepare: SQL Server - select * from cncuser.tbldia
>where diatblname = ?
>2       18:45:24  SQL Data In: SQL Server - Rows affected = 0
>3       18:45:24  SQL Stmt: SQL Server - Close

>The BDE didn't supply the parameter data!!!!.   You get an error -
>"Operation Not Applicable".

>If you define a System DSN in the ODBC, both BDE4 and BDE5 will pull this
>info in automatically and create an alias of the same name as the System
>DSN.  This uses the BDE "SQL Server" database driver.

>In BDE4, you could create an alias using the MSSQL database driver and
>connect directly to the SQL server without defining anything in the ODBC.

>In BDE5, the MSSQL driver is gone - there is no direct connection to the SQL
>Server.  There is a SQL Server database driver, but this must be used in
>conjunction with an ODBC DSN.

>The question is - is this a setup problem or a real problem?  Is there a
>work-around?  With BDE4/5 using ODBC, what makes it{*word*222}up with ODBC 3.5.

>Any comments or help would be greatly appreciated.

>- Craig

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


It gets worse.  Besides parameterized queries not working, a filter on a
TTable does not work.

Somehow, a filter of (DiaTblName='') got translated into this

 ?"DiaTblName"=? AND ("DiaTblName" = ?)

in the where clause.  Like the parameterized query, the actual parameters
were not supplied to thw ODBC - thus the error like before : "Operation Not
Applicable".

1       11:19:13  SQL Prepare: SQL Server - SELECT "DiaTblName"
,"BitDiameter" ,"ProcessParam"  FROM "CncUser"."TblDiaParam" WHERE
"DiaTblName"=? AND ("DiaTblName" = ?) ORDER BY  "DiaTblName" ASC ,
"BitDiameter" ASC
2       11:19:13  SQL Data In: SQL Server - Param = 1, Name = DiaTblName,
Type = fldZSTRING, Precision = 50, Scale = 0, Data = CRAIG
3       11:19:13  SQL Stmt: SQL Server - Close
4       11:21:02  Log started for: Delphi 3.SessionThreadBuild
5       11:21:04  SQL Transact: SQL Server - XACT Abort
6       11:21:04  SQL Vendor: ODBC - SQLTransact
7       11:21:04  SQL Connect: SQL Server - Disconnect GENERAL
8       11:21:04  SQL Vendor: ODBC - SQLDisconnect
9       11:21:04  SQL Vendor: ODBC - SQLFreeConnect

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


This kind of calls up the debate about whether or not parameterized queries
are really worth the effort... BTW, I use D4/BDE 5 w/SQL Server 6.5 with no
problems.

For all intents and purposes, if you're not using stored procedures on the
back-end, you're doing pass-through SQL. So the debate is this: Why use
parameterized queries at all instead of merely setting up your SQL statement
with the variable values _before_ you execute the SQL? For example, here's
some code that I pulled from one of my programs:

  with sqlEI do begin
    SessionName := sesProc.SessionName;
    DatabaseName := dbCross.DatabaseName;
    with SQL do begin
      Clear;
      Add('SELECT DISTINCT Episode, PatientID, Min(StartDate) as
StartDate');
      Add('INTO ' + GetSQLDBPath(dbCross.DatabaseName) + '..EpiTemp1');
      Add('FROM ' + GetSQLDBPath(dbCross.DatabaseName) + '.' + sCrossTbl);
      Add('WHERE (Episode > 0) AND (PatientID <> ''' + sPatient + '''');
      Add('GROUP BY Episode, PatientID');
      try
        ExecSQL;
      finally
        Free;
        sqlEI := nil;
      end;
    end;
  end;

GetSQLDBPath merely returns the name of the database as defined in my MSSQL
driver wrapping the Session.GetAliasPath method. BTW, I'm surprised to hear
that you don't have the MSSQL driver because it was included with my version
of the BDE 5.

Okay, moving on...

The variable sCrossTbl represents a table name that I want to query against
(not something you can do with a parameterized query) and sPatient is a
string variable representing a patient I don't want to include in the query
(something normally used in a parameterized query).

Notice that the code actually employs MS TransactSQL to perform the query.
That way, using a SELECT INTO, I can save the results on the server for
later use. All this was done using pure pass-through, without having to use
a parameter, and without having to prepare the query. Employing this
technique has never yielded any untoward results (unless I did something
really stupid with the DB config).

Also, because I don't need to prepare the query before running it, I don't
have to worry about the server eating up cycles preparing my queries. It
just executes them as it goes. Granted, it may impose a bit more processing
time on the client side, but that's negligible.

I know, some people will probably say, "That technique shoots cross-platform
capabilities to hell." But my reply is this: SQL Server is my back-end
platform and has been for the past three years. Period. I don't intend to
cross platforms any time soon. So I'm going to use the most optimized
technique I can.

I'd be interested in hearing some feedback on this. Am I full of shit? I
don't know. But I've had continued success with very few failures for past
couple of years employing this technique.

Brendan

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


Accessing SQL server data via ODBC 3.5 and BDE 4/5.  I assume that this is a
legal setup since it works using ODBC 3.0x.

The fact that a parameterized query and a filter on a table doesn't work
seems like a pretty big deal.  You can write your own query to eliminate the
parameterized query, but many third party tools such as InfoPower use the
filter and query functions to perform many of their neat tricks.

The work-around for me is to use the C/S SQL Link (MSSQL) directly and avoid
the ODBC altogether.  I don't know if this is a Borland ploy to get you to
buy the Delphi C/S to access a SQL Server database - but it seems like it.

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


Quote
Craig M. Pulford wrote in message <6qt2kv$5a...@forums.borland.com>...
> The work-around for me is to use the C/S SQL Link (MSSQL) directly and
avoid
> the ODBC altogether.

<snip>
Some of our spenders can't afford or will not budget for C/S and have to use
Pro when upgrading to version 4 of Delphi.  Times get tough when the version
you used to use becomes an overkill.

Quote
> I don't know if this is a Borland ploy to get you to buy the Delphi C/S to
access a
> SQL Server database - but it seems like it.

I think it is a Microsoft ploy rather than Borland because the SQLSRV32.DLL
was written by Microsoft if I'm not mistaken...

Scott

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


Woah Where is my soapbox........

I bought my own copy of D3 C/S just over a year ago and it cost me
1200 ukp - if I now upgrade D3 C/S it is going to cost me 1300ukp.  If
I hadn't bought it I could buy the full version for 1600ukp.  So as a
loyal customer of Borland's it will cost me 2500ukp for D4 C/S but a
newcomer pays 900ukp less.  My answer to Borland is that in a couple
of months I am going to buy Visual Studio 6 Enterprise which I can get
for 600ukp......Until they (Inprise) come to their senses I am not
even considering upgrading....I would be quite prepared to pay the
400ukp difference but I am not going to be screwed by inprise in this
way.

Not a happy bunny!

Terry Murphy

On Thu, 13 Aug 1998 16:47:01 +1000, "Scott Ritter"

Quote
<rit...@bblfm.com.au> wrote:
>Craig M. Pulford wrote in message <6qt2kv$5a...@forums.borland.com>...

>> The work-around for me is to use the C/S SQL Link (MSSQL) directly and
>avoid
>> the ODBC altogether.
><snip>
>Some of our spenders can't afford or will not budget for C/S and have to use
>Pro when upgrading to version 4 of Delphi.  Times get tough when the version
>you used to use becomes an overkill.

>> I don't know if this is a Borland ploy to get you to buy the Delphi C/S to
>access a
>> SQL Server database - but it seems like it.

>I think it is a Microsoft ploy rather than Borland because the SQLSRV32.DLL
>was written by Microsoft if I'm not mistaken...

>Scott

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


Yes Brendan have you ever noticed that whever the borland / microsoft
/ oracle / informix etc  tug o war breaks delphi you can always rely
on this technique.  It still isn't as fast as pre-compiled sps but by
the time I am pissed off enough to do this I am worried whether I am
going to get the code in questioin to work at all. Notice that delphi
Stored procedure components also seem particulary robust of course all
they are doing is calling pre compiled Transact SQL.  Do we sense a
pattern here?  I know I must be getting cynical in my old age :-)

Terry Murphy

On Wed, 12 Aug 1998 12:21:01 -0700, "Brendan Delumpa"

Quote
<bdelumpaNOS...@delumpa.com> wrote:
>This kind of calls up the debate about whether or not parameterized queries
>are really worth the effort... BTW, I use D4/BDE 5 w/SQL Server 6.5 with no
>problems.

>For all intents and purposes, if you're not using stored procedures on the
>back-end, you're doing pass-through SQL. So the debate is this: Why use
>parameterized queries at all instead of merely setting up your SQL statement
>with the variable values _before_ you execute the SQL? For example, here's
>some code that I pulled from one of my programs:

>  with sqlEI do begin
>    SessionName := sesProc.SessionName;
>    DatabaseName := dbCross.DatabaseName;
>    with SQL do begin
>      Clear;
>      Add('SELECT DISTINCT Episode, PatientID, Min(StartDate) as
>StartDate');
>      Add('INTO ' + GetSQLDBPath(dbCross.DatabaseName) + '..EpiTemp1');
>      Add('FROM ' + GetSQLDBPath(dbCross.DatabaseName) + '.' + sCrossTbl);
>      Add('WHERE (Episode > 0) AND (PatientID <> ''' + sPatient + '''');
>      Add('GROUP BY Episode, PatientID');
>      try
>        ExecSQL;
>      finally
>        Free;
>        sqlEI := nil;
>      end;
>    end;
>  end;

>GetSQLDBPath merely returns the name of the database as defined in my MSSQL
>driver wrapping the Session.GetAliasPath method. BTW, I'm surprised to hear
>that you don't have the MSSQL driver because it was included with my version
>of the BDE 5.

>Okay, moving on...

>The variable sCrossTbl represents a table name that I want to query against
>(not something you can do with a parameterized query) and sPatient is a
>string variable representing a patient I don't want to include in the query
>(something normally used in a parameterized query).

>Notice that the code actually employs MS TransactSQL to perform the query.
>That way, using a SELECT INTO, I can save the results on the server for
>later use. All this was done using pure pass-through, without having to use
>a parameter, and without having to prepare the query. Employing this
>technique has never yielded any untoward results (unless I did something
>really stupid with the DB config).

>Also, because I don't need to prepare the query before running it, I don't
>have to worry about the server eating up cycles preparing my queries. It
>just executes them as it goes. Granted, it may impose a bit more processing
>time on the client side, but that's negligible.

>I know, some people will probably say, "That technique shoots cross-platform
>capabilities to hell." But my reply is this: SQL Server is my back-end
>platform and has been for the past three years. Period. I don't intend to
>cross platforms any time soon. So I'm going to use the most optimized
>technique I can.

>I'd be interested in hearing some feedback on this. Am I full of shit? I
>don't know. But I've had continued success with very few failures for past
>couple of years employing this technique.

>Brendan

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


test

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


I have noticed this problem about a month ago, but didn't want to waste
time for searching the error, because I had no time, so I used another
solution. I had a procedure ( "x" ) do display records from a database
which were currently in a package (this proc just closed the query with a
predefined sql-statement, set two parameters and opened it again). As I
noticed that it doesn't work I split the sql-statement into several lines,
so that every parameter was in its own line (the query had just 3 lines).
And then, instead of changing the parameter-values of the query I made the
procedure ("x") to change the lines in the query's sql-statement. The rest
of the application hadn't to be changed because the procedure call was
still the same (with two parameter-variables).

OK, so far this wasn't a real problem

But 2 days ago I noticed, that the TStoredProc had the same problems as
TQuery. So the last 48 hours I spent with searching for a solution, before
I had to accept that it wasn't an error (this was a short time before I
found this newsgroup) and something was going on on my system (I wasn't
very far from the decision to reinstall everything), but then I had the
Idea to call a stored procedure through the TQuery component - it worked
and it still works. So, if you don't have an "{*word*118}" sql-statement and
just want to open or execute a query or call a stored procedure (with
parameters) - just split the sql-statement into several lines, write a
procedure, that changes the "parameters"(deletes and inserts) and opens
this query.

A more comfortable solution (I just had this idea) is to write a
"universal" procedure, that changes the parameters in the sql-statement of
any query, using the fieldname passed in the statement as the
parameter-name, such as:

------------------------
SELECT field_a, field_b, field_c, field_d, field_f FROM xxx WHERE
field_a=''
AND
field_b=0
-----------------------

Pass "standart" values as criteria, such as '' for a (var)char (string)
field, 0 for an integer field and s. o.

your "universal" procedure will just have to find the field name and to
place the value after the vildcart characters ( e. g. =, <, >, <>, NOT,
LIKE)

Ok maybe it' s shit, but the first 2 solutions it work, and the last one
should work too;

For somebody, who likes "real" parameters: Create a TStrings component, use
a special string combination before the parameters name in your queries to
indicate parameters (but not ":"), everytime you want your application to
open a query, copy the SQL property of that query into your TStrings
component, let a procedure replace parameters with values (in the
property), when you have used the query - clear the SQL property and put
the original sql-statement from the TStrings component into it and clear
the TStrings component

may be that the last one is shit too (I haven't tried it), but if any of
you have another solutions, please let me know

thank you for your solutions

I' ve tried to report this bug to MS, but their page (they have this "bug
report page") wasn't accessible -  isn't that corious?

Alex B. , 17

PS: My real adress is the same as you can see  without "nojunk" >>
cool_runn "at" hotmail.com

----------

Quote
> From: Craig M. Pulford <c...@uComDesign.com>
> Newsgroups: borland.public.delphi.database.sqlservers
> Subject: BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem
> Date: Mittwoch, 12. August 1998 00:53

> Using Delphi 3.02 C/S, BDE 5.0, ODBC 3.5, and SQL Server 6.5.

> A parameterized query of the form

> select * from cncuser.tbldia where
> diatblname = :diatblname

> This works against a Paradox and Access table.  It works with BDE  4/5
and
> ODBC 3.0x against a SQL Server database.  The problem occurs using the
> latest ODBC 3.5 with BDE 4 or 5.

> Monitored SQL with BDE 4/5 and ODBC 3.0x

> 1       17:39:17  SQL Prepare: SQL Server - select * from cncuser.tbldia
> where diatblname=?
> 2       17:39:17  SQL Data In: SQL Server - Param = 1, Name = , Type =
> fldZSTRING, Precision = 5, Scale = 0, Data = craig
> 3       17:39:17  SQL Execute: SQL Server - select * from cncuser.tbldia
> where diatblname=?

> Monitored SQL with BDE 4/5 and ODBC 3.5

> 1       18:45:24  SQL Prepare: SQL Server - select * from cncuser.tbldia
> where diatblname = ?
> 2       18:45:24  SQL Data In: SQL Server - Rows affected = 0
> 3       18:45:24  SQL Stmt: SQL Server - Close

> The BDE didn't supply the parameter data!!!!.   You get an error -
> "Operation Not Applicable".

> If you define a System DSN in the ODBC, both BDE4 and BDE5 will pull this
> info in automatically and create an alias of the same name as the System
> DSN.  This uses the BDE "SQL Server" database driver.

> In BDE4, you could create an alias using the MSSQL database driver and
> connect directly to the SQL server without defining anything in the ODBC.

> In BDE5, the MSSQL driver is gone - there is no direct connection to the
SQL
> Server.  There is a SQL Server database driver, but this must be used in
> conjunction with an ODBC DSN.

> The question is - is this a setup problem or a real problem?  Is there a
> work-around?  With BDE4/5 using ODBC, what makes it{*word*222}up with ODBC
3.5.

> Any comments or help would be greatly appreciated.

> - Craig

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


Quote
>I bought my own copy of D3 C/S just over a year ago and it cost me
>1200 ukp - if I now upgrade D3 C/S it is going to cost me 1300ukp.  If
>I hadn't bought it I could buy the full version for 1600ukp.  So as a
>loyal customer of Borland's it will cost me 2500ukp for D4 C/S but a
>newcomer pays 900ukp less.

I apologize if this seems a bit strong, but your assessment that you're
somehow paying more for D4 is absurd!  You've been USING D3 for over a
year...  That's less than 100ukp per month (not even considering tax
benefits), and that number decreases with each day that you continue to use
D3.  Personally, I don't consider that to be a particularly unreasonable
price to pay for the technology tool that enables me to earn my living.
(The servers I use cost significantly more than that.)  So the reality is
that you've been earning money using their product for over a year, and now
Inprise is giving you a 300ukp break on the next version.  Further, if you
don't think the next version is worth the money, no one's forcing you to buy
it.  (Although you can probably save a couple of thousand dollars of
development costs pretty quickly given the productivity enhancements in D4.)

In my opinion, the real problem here is that we've been spoiled by how
artificially cheap database prices have been over the past several years.
Unfortunately, Inprise doesn't have a cash cow like DOS or Windows to enable
them to sell other products at a loss for years at a time.  Subsequently,
they have not been able to penetrate the market and gain the economies of
scale necessary to sell Delphi at the same price point as Access/VB.  The
question is, what product do you think will better serve you and your
clients?

In fairness, I too would prefer to pay less for the tools I need to do my
job (who wouldn't?).  Still, I realize that Inprise is a business, and like
all businesses, it needs to sell some products at reasonable margins.

Trying to look at it objectively, I think that Inprise has shown great
thought in their pricing strategies.  The non-C/S versions have been, and
continue to be "popularly priced."  The C/S version, which is typically used
to create large-scale applications, is priced higher because the cost of the
tool becomes small in comparison to the overall project costs.  (This
pricing policy also seems to extend to the MIDAS license, which is free when
used in a 2-tier app, but costs $5000 per server in a multi-tier app.  I
have seen a huge number of people balk at this fee, but the cost of the per
server royalty is dwarfed in comparison to the costs associated with true
multi-tier development.)

Now I agree that there are legitimate small-scale C/S projects, and for
these the product cost seems high in relation to competitors' offerings.  I
also think it would be nice for Inprise to make certain functionality such
as TClientDataSet (allowing thin-client and legitimate cached updates)
available in a non-C/S package.  (Perhaps this is something they will
consider doing in the future if they hear about it from enough people.)

Quote
>in a couple of months I am going to buy Visual Studio 6 Enterprise
>which I can get for 600ukp......Until they (Inprise) come to their senses
>I am not even considering upgrading....I would be quite prepared to
>pay the 400ukp difference

I'm sure you'll end up doing what you believe is best for yourself and your
clients.  All I'm saying is that when you amortize the cost of the software
over its useful life, I think the investment in the "right" tool may not
seem quite so large.

-- Mark

Re:BDE 5.0/ODBC 3.5/SQL Server : Parameterized Query Problem


It isn't a pricing complaint it is an attitude complaint!

I must make the observation that it is the small shops and not the
Suits who have kept Borland afloat over the years.  There is no doubt
that they are going to lose the small shops that used to do
Nantucket/CA Clipper that chose Delphi over Visual Basic four or five
yeas ago.  I just look around my local Delphi User group and I find
that I first met tham all (almost) at Clipper user groups.   If they
lose the small shops (and I know of two other such cases) then no
amount of innovative pricing is going to help them at all if they
(Inprise) go down the tubes. Then we will all have to buy our tools
from world domination central.  This more than anything is why I am so
pissed off with Inprise.  I don't like programming in Basic.  The
Suits at Inprise should wake up and realise that the Suits WITH the
money in IT departments and Suits in project management out there in
the real world WANT to buy Microsoft.  There was a time when 'no one
ever got fired for buying IBM'  well happiness is a warm backside if
you are in charge of developing a mission critical app.  Microsoft to
them looks a good bet.

I am not responsible for the fact that Inprise is not as successful as
Microsoft.  Because this line of argument means that I should treat
Inprise as a charity.   Microsoft has dos to milk and therefore I
should allow Inprise to milk me.  Duh!

As a contractor I want hundreds and thousands of MS SQL Servers out
there so I have a large demand for my main skills which keeps rates
high and I don't give a {*word*99} if Microsoft give them away.

'artificially cheap database prices'  Now there is an asurdity  -
Maybe we should slap a couple of thousand pounds on the price of all
software to make sure that only the right sort of organisations that
do legitimate Client Server apps can afford them.  This of course
would mean less jobs for programmers and IT suppliers of all kinds.
Hey great idea where do I sign up NOT!  

Elementary economics should tell you that you have to charge the
market price for goods unless you have a cartel that fixes the price
or there are no substitute goods.  Cartels are illegal and would in
any case be impossible to operate in this industry now simply because
there are such a wide range of substitues availlable.  Inprise must
think that they are a monopoly supplier to the people who use this
product - bad move.

This has nothing to do with amortizing the software because on these
grounds I would have upgraded my VB4 Professional to VB5 Enterprise
for less than half the price I paid for D3.  What was the upgrade
price from D1 C/S to D2 C/S and what was the upgrade price from D2 C/S
to D3 C/S are what Inprise needs to face up to and give me a good
reason why they have decided after giving such thought to their
pricing strategies come up with this lemon!

Terry Murphy

On Sun, 16 Aug 1998 21:20:53 -0400, "Mark Pauker"

Quote
<mpau...@mci2000.com> wrote:
>>I bought my own copy of D3 C/S just over a year ago and it cost me
>>1200 ukp - if I now upgrade D3 C/S it is going to cost me 1300ukp.  If
>>I hadn't bought it I could buy the full version for 1600ukp.  So as a
>>loyal customer of Borland's it will cost me 2500ukp for D4 C/S but a
>>newcomer pays 900ukp less.

>I apologize if this seems a bit strong, but your assessment that you're
>somehow paying more for D4 is absurd!  You've been USING D3 for over a
>year...  That's less than 100ukp per month (not even considering tax
>benefits), and that number decreases with each day that you continue to use
>D3.  Personally, I don't consider that to be a particularly unreasonable
>price to pay for the technology tool that enables me to earn my living.
>(The servers I use cost significantly more than that.)  So the reality is
>that you've been earning money using their product for over a year, and now
>Inprise is giving you a 300ukp break on the next version.  Further, if you
>don't think the next version is worth the money, no one's forcing you to buy
>it.  (Although you can probably save a couple of thousand dollars of
>development costs pretty quickly given the productivity enhancements in D4.)

>In my opinion, the real problem here is that we've been spoiled by how
>artificially cheap database prices have been over the past several years.
>Unfortunately, Inprise doesn't have a cash cow like DOS or Windows to enable
>them to sell other products at a loss for years at a time.  Subsequently,
>they have not been able to penetrate the market and gain the economies of
>scale necessary to sell Delphi at the same price point as Access/VB.  The
>question is, what product do you think will better serve you and your
>clients?

>In fairness, I too would prefer to pay less for the tools I need to do my
>job (who wouldn't?).  Still, I realize that Inprise is a business, and like
>all businesses, it needs to sell some products at reasonable margins.

>Trying to look at it objectively, I think that Inprise has shown great
>thought in their pricing strategies.  The non-C/S versions have been, and
>continue to be "popularly priced."  The C/S version, which is typically used
>to create large-scale applications, is priced higher because the cost of the
>tool becomes small in comparison to the overall project costs.  (This
>pricing policy also seems to extend to the MIDAS license, which is free when
>used in a 2-tier app, but costs $5000 per server in a multi-tier app.  I
>have seen a huge number of people balk at this fee, but the cost of the per
>server royalty is dwarfed in comparison to the costs associated with true
>multi-tier development.)

>Now I agree that there are legitimate small-scale C/S projects, and for
>these the product cost seems high in relation to competitors' offerings.  I
>also think it would be nice for Inprise to make certain functionality such
>as TClientDataSet (allowing thin-client and legitimate cached updates)
>available in a non-C/S package.  (Perhaps this is something they will
>consider doing in the future if they hear about it from enough people.)

>>in a couple of months I am going to buy Visual Studio 6 Enterprise
>>which I can get for 600ukp......Until they (Inprise) come to their senses
>>I am not even considering upgrading....I would be quite prepared to
>>pay the 400ukp difference

>I'm sure you'll end up doing what you believe is best for yourself and your
>clients.  All I'm saying is that when you amortize the cost of the software
>over its useful life, I think the investment in the "right" tool may not
>seem quite so large.

>-- Mark

Go to page: [1] [2]

Other Threads