SQL API in P.2000 
Author Message
 SQL API in P.2000

Hello,

I think it's time to put some pressure on Pervasive to rethink the decision
to drop the native SQL API in P.2000.
We are using the Titan Delphi components for some years now, which are quite
stable and fast. The query component uses (as I suppose many other
developers) the native SQL API, and for the moment there is no support for
P.2000 because of this.

Another point is, that using SQL will result in using ODBC. I don't want to
think about installing and configuring ODBC on the PCs of our customers (or
am I wrong in ths point)?

For me, it seems Pervasive made the second BIG wrong decision in short time.
The first was the try to drop peer-to-peer with P.SQL. Where does Pervasive
wants to go?

In a discussion forum on the Titan website (www.reggatta.com) is a thread
about changing to MS! Is that what Pervasive wants?

Looking forward to other opinion,

 Arnd Iffland



Sun, 24 Mar 2002 03:00:00 GMT
 SQL API in P.2000


<<snip>>

Quote:
> Another point is, that using SQL will result in using ODBC. I don't want
to
> think about installing and configuring ODBC on the PCs of our customers
(or
> am I wrong in ths point)?

<<snip>>

I also am worried about the problems of configuring ODBC on customer PCs -
can it be a trouble-free process?

- James Alston



Sun, 24 Mar 2002 03:00:00 GMT
 SQL API in P.2000
It's a real mystery to me why they dropped the 6.15. I uses 6.15 now, and
will not upgrade to SQL. It's far too expensive for my customers. It's
doesn't have peer-to-peer support. Most of my customers doesn't have a
network or have a small network, what they are given is the stable  and
crash freeing that comes with 6.15.

I have tested a lot of databases (or the REAL word *record managers*). The
built in BDE in Delphi really sucks. And it's so unstable that it's
completly useless.

I know (or I belive) that Pervasive did a mistake then they dropped the
6.15. Everything is not networkning. Everything is not networking with
100-10000 users. There IS a large market bite with standalone users and
companys with 2-9 users.

And for them the 6.15 would be what they need.

You are selling your soul Pervasive!

LB Cid


Quote:


><<snip>>
>> Another point is, that using SQL will result in using ODBC. I don't want
>to
>> think about installing and configuring ODBC on the PCs of our customers
>(or
>> am I wrong in ths point)?

><<snip>>

>I also am worried about the problems of configuring ODBC on customer PCs -
>can it be a trouble-free process?

>- James Alston



Mon, 25 Mar 2002 03:00:00 GMT
 SQL API in P.2000


Couldn't agree more.

There is probably good reason why other DB companies didn't make that
move (droping their native API and rely on ODBC) .

What about market where client platforms don't support
ODBC or exist in text mode only ? Too small ?

Best,
Davorin P.

Quote:
>Hello,

>I think it's time to put some pressure on Pervasive to rethink the decision
>to drop the native SQL API in P.2000.
>We are using the Titan Delphi components for some years now, which are quite
>stable and fast. The query component uses (as I suppose many other
>developers) the native SQL API, and for the moment there is no support for
>P.2000 because of this.

>Another point is, that using SQL will result in using ODBC. I don't want to
>think about installing and configuring ODBC on the PCs of our customers (or
>am I wrong in ths point)?

>For me, it seems Pervasive made the second BIG wrong decision in short time.
>The first was the try to drop peer-to-peer with P.SQL. Where does Pervasive
>wants to go?

>In a discussion forum on the Titan website (www.reggatta.com) is a thread
>about changing to MS! Is that what Pervasive wants?

>Looking forward to other opinion,

> Arnd Iffland



Mon, 25 Mar 2002 03:00:00 GMT
 SQL API in P.2000

Quote:
>For me, it seems Pervasive made the second BIG wrong decision in short
time.
>The first was the try to drop peer-to-peer with P.SQL. Where does Pervasive
>wants to go?

Same problem for me!
Does Pervasive not need the "small" customers? Does Pervasive only want to
support "large" environments in the future? We are using BTRIEVE-engines
for more than 10 years now, but it seems we have to change.
Why do developers have to change their code if using SQL-API and want to
upgrade to P.SQL 2000. I am glad that they kept the transactional API what
we are using most. I also did not manage till now to get the WG-engine
working
in a WG. Hope that Pervasive will think about their product twice.

Christian



Fri, 29 Mar 2002 03:00:00 GMT
 SQL API in P.2000
It seems that Pervasive is not very interested what the developers think.
I knew there where some guys from Pervasive who are reading this group, but
they havn't appeared in this thread till now.
Isn't there something they want to tell us before everybody is searching for
an alternative?

Greetings,

Arnd Iffland



Sat, 30 Mar 2002 03:00:00 GMT
 SQL API in P.2000

Quote:
>It seems that Pervasive is not very interested what the developers think.
>I knew there where some guys from Pervasive who are reading this group, but
>they havn't appeared in this thread till now.
>Isn't there something they want to tell us before everybody is searching
for
>an alternative?

What I'm looking for is a kind of P.2000-light. that could be used in
single-version as well as in a small peer-to-peer network.

I've found that Btrieve 6.15 is one of the most stable and reliable
databases (record managers) on the market. SQL? If I have a large table
(registerfile), I can always use the ExtendedGet-ops to recive a match
criteria very fast. Or if I realy has the need, of cource would I use
P.2000.

No, I'm sorry to say - Pervasive seems to fall in the same basket as
Microsoft. The little user has no value. But I say it's always better to
sell 1000 pcs for $5 than sell 5 pcs for $5000.

P.2000 isn't bad, it's just not suitable for small projects (single users,
and *small* networks)

Pervasie could easily take a look a B 6.15, and give to us what we want. Now
Pervasive have closed the door. They haven't opened it dispite all the
knocking that I, and all other is doing.

Pervasive? Hello?

LB Cid



Sat, 30 Mar 2002 03:00:00 GMT
 SQL API in P.2000
They have some dillusion that they can go head-to-head with REAL large scale
databases.
Some moron thinks that this can only be done by burning some bridges.

Wise man once say:
While you hunt for big bufallo don't burn crops to grow grazing grass......


Quote:
> >For me, it seems Pervasive made the second BIG wrong decision in short
> time.
> >The first was the try to drop peer-to-peer with P.SQL. Where does
Pervasive
> >wants to go?

> Same problem for me!
> Does Pervasive not need the "small" customers? Does Pervasive only want to
> support "large" environments in the future? We are using BTRIEVE-engines
> for more than 10 years now, but it seems we have to change.
> Why do developers have to change their code if using SQL-API and want to
> upgrade to P.SQL 2000. I am glad that they kept the transactional API what
> we are using most. I also did not manage till now to get the WG-engine
> working
> in a WG. Hope that Pervasive will think about their product twice.

> Christian



Sat, 30 Mar 2002 03:00:00 GMT
 SQL API in P.2000
To everyone in this this thread.  I apologize for
the length of this post, but I have taken the
liberty of reproducing a note that I sent to
Pervasive concerning this topic.  I hope you will
agree that it covers our concerns.

<addressed to Pervasive employee Mike Peloquin>

This note (at your request) is designed to detail
some of the issues that we have faced over the
last twelve months while developing our 32-bit
software suite.  Thanks to some business
decisions made at Pervasive, our product line's
competitiveness has been seriously compromised.

We have been Btrieve users since the early 90's.
We purchased an unlimited distribution license
for Btrieve 6.15 in (I believe) 1996.  At that
time, we had three programs (LubriScan, Prism
Pro, and Asset Manager) all of which were Windows
programs using Btrieve.  We were happy with
performance of Btrieve, with its robustness and
by the ability to set up small networks of 3-4
simultaneous users with acceptable performance.

We began to develop our 32-bit replacement for
LubriScan and Prism Pro in late 1997, using
Btrieve 6.15.  When Pervasive 7 was announced,
with its combined transactional and relational
data access, we decided that the ability to
access data using SQL was a competitive
advantage, so we decided (with considerable
carrot-and-stick prodding from Pervasive) to make
the move to P.7.  We built a query system using
the Scalable SQL interface, and built our report
generation system around the query system.  We
were somewhat disappointed with P.7s SQL
performance, but it was deemed acceptable for
what we were using it for.

The first shock was the discovery that P.7
Workstation would not allow shared access to data
on a LAN.  Our entire pricing scheme for multi-
user systems was immediately thrown out the
window, as it was necessary now to move even
small numbers of users to 10-user networks -
forcing users to pay for functionality that they
would never use.  Most of our customers have
three or four maintenance engineers using our
system - usually never more than two at once.
Some of our systems are priced at less than $1000
- a price structure that is made completely
untenable by the requirement that people that
want two simultaneous users now require a 10-user
network license.

This situation is most critical in the case of
our major OEM, <name omitted>. - they have over
400 users and 100 of them are small 2-3 user
nets.  They will certainly not be willing to
accept a price of $600-700 for a net license for
their user base.

The announcement of the Workgroup version of
Pervasive.SQL seemed to solve some of these
issues, but of course those hopes were quickly
dashed when it was revealed that in Pervasive.SQL
2000 the Scalable SQL API was being arbitrarily
dropped in favour of the ODBC API.  This meant
that our SQL interface (and report engine) would
not work on Pervasive.SQL 2000.  The fact that
this interface was dropped without so much as a
obsolescence announcement is an arrogance I have
never seen in all my years as a developer.  Even
Microsoft treats its developers with more regard
than that!

In any event, we are now well and truly stuck.
We can't go forwards, we can't go backwards and
we are being forced into a pricing model that
will make our new technology very unattractive in
comparision to what it is replacing.

My OEMs are unimpressed with the fact that we are
using what (in their eyes) seems to be an
expensive, obscure, and poorly performing (at
least the SQL part) database engine.  They ask
me, why don't we use SQL Server?  Its well-known,
it has a 5-user version at about $400US and its
Trans-SQL runs rings around this Pervasive
thing.  And half of our customers already have it
anyway, so they don't even need to buy it!  And
we can use the Workstation SQL Server for free!

Anyway, I need some answers, or I will shift our
32-bit product away from Pervasive.  What I need
to hear is:

1.  I need a client-server version of the system
for a smaller number of users that I can purchase
at a significantly lower price than the 10-user
version ($650 at provantage.com  is the cheapest
I've been able to get)

2.  A solid assurance that any conversion that we
undertake towards Pervasive.SQL 2000 won't be
wasted by another arbitrary decision - and by
solid I don't mean some salesman telling me "Oh,
yeah, we'll never do THAT again!" - I want it in
writing.

3.  Some useful technical assistance in our SQL
conversion process - most of the time my
developers find out stuff to tell your support
people.  We were once informed by one of tech
people, that when we read in the documentation
that we could store binary large objects of up to
2GB using Pervasive.SQL, and we found out that
you were actually limited to 32KB, a support
person told us, quote "Oh, thats a bug in the
documentation"!!!  Please.  We can take care of
ourselves, we just need some advice on how best
to proceed - let us talk to someone who actually
knows something about your product.

4.  Assurance (in writing) that if I buy an
unlimited distribution license for Pervasive.SQL
7, that it will extend to Pervasive.SQL 2000 and
(to a reasonable extent) whatever comes after
that.

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 31 Mar 2002 03:00:00 GMT
 SQL API in P.2000
ODBC does cause a major problem for set-up of workstations...

Does anyone know...

Is it possible to write a program to set-up the data source on every
workstation.

Up until now using the Btrieve API and the old SQL API all we needed
was a data path which we added to the applications shortcut.

Is it possible to create an ODBC data source just from a datapath?

Pat

Sent via Deja.com http://www.deja.com/
Before you buy.



Mon, 01 Apr 2002 03:00:00 GMT
 SQL API in P.2000
Steve,
Your concerns and problems are similar to our own. We have to stick with
Pervasive in the short term to get a new release out the door- but we are
looking really hard at moving away from Pervasive.SQL as soon as possible.

Every one of their recent announcements (ie. dropping of unlimited licences,
dropping 6.15, workstation vs workgroup fiasco, dropping of Scalable SQL)
has hurt our company financially. With friends like this, who needs
enemies! - and who knows what's next??  We can't take any more "surprises"
from Pervasive, which is very disappointing since our company has been using
Btrieve in various versions for over 10 years.

Greg


Quote:
> To everyone in this this thread.  I apologize for
> the length of this post, but I have taken the
> liberty of reproducing a note that I sent to
> Pervasive concerning this topic.  I hope you will
> agree that it covers our concerns.

> <addressed to Pervasive employee Mike Peloquin>

> This note (at your request) is designed to detail
> some of the issues that we have faced over the
> last twelve months while developing our 32-bit
> software suite.  Thanks to some business
> decisions made at Pervasive, our product line's
> competitiveness has been seriously compromised.

> We have been Btrieve users since the early 90's.
> We purchased an unlimited distribution license
> for Btrieve 6.15 in (I believe) 1996.  At that
> time, we had three programs (LubriScan, Prism
> Pro, and Asset Manager) all of which were Windows
> programs using Btrieve.  We were happy with
> performance of Btrieve, with its robustness and
> by the ability to set up small networks of 3-4
> simultaneous users with acceptable performance.

> We began to develop our 32-bit replacement for
> LubriScan and Prism Pro in late 1997, using
> Btrieve 6.15.  When Pervasive 7 was announced,
> with its combined transactional and relational
> data access, we decided that the ability to
> access data using SQL was a competitive
> advantage, so we decided (with considerable
> carrot-and-stick prodding from Pervasive) to make
> the move to P.7.  We built a query system using
> the Scalable SQL interface, and built our report
> generation system around the query system.  We
> were somewhat disappointed with P.7s SQL
> performance, but it was deemed acceptable for
> what we were using it for.

> The first shock was the discovery that P.7
> Workstation would not allow shared access to data
> on a LAN.  Our entire pricing scheme for multi-
> user systems was immediately thrown out the
> window, as it was necessary now to move even
> small numbers of users to 10-user networks -
> forcing users to pay for functionality that they
> would never use.  Most of our customers have
> three or four maintenance engineers using our
> system - usually never more than two at once.
> Some of our systems are priced at less than $1000
> - a price structure that is made completely
> untenable by the requirement that people that
> want two simultaneous users now require a 10-user
> network license.

> This situation is most critical in the case of
> our major OEM, <name omitted>. - they have over
> 400 users and 100 of them are small 2-3 user
> nets.  They will certainly not be willing to
> accept a price of $600-700 for a net license for
> their user base.

> The announcement of the Workgroup version of
> Pervasive.SQL seemed to solve some of these
> issues, but of course those hopes were quickly
> dashed when it was revealed that in Pervasive.SQL
> 2000 the Scalable SQL API was being arbitrarily
> dropped in favour of the ODBC API.  This meant
> that our SQL interface (and report engine) would
> not work on Pervasive.SQL 2000.  The fact that
> this interface was dropped without so much as a
> obsolescence announcement is an arrogance I have
> never seen in all my years as a developer.  Even
> Microsoft treats its developers with more regard
> than that!

> In any event, we are now well and truly stuck.
> We can't go forwards, we can't go backwards and
> we are being forced into a pricing model that
> will make our new technology very unattractive in
> comparision to what it is replacing.

> My OEMs are unimpressed with the fact that we are
> using what (in their eyes) seems to be an
> expensive, obscure, and poorly performing (at
> least the SQL part) database engine.  They ask
> me, why don't we use SQL Server?  Its well-known,
> it has a 5-user version at about $400US and its
> Trans-SQL runs rings around this Pervasive
> thing.  And half of our customers already have it
> anyway, so they don't even need to buy it!  And
> we can use the Workstation SQL Server for free!

> Anyway, I need some answers, or I will shift our
> 32-bit product away from Pervasive.  What I need
> to hear is:

> 1.  I need a client-server version of the system
> for a smaller number of users that I can purchase
> at a significantly lower price than the 10-user
> version ($650 at provantage.com  is the cheapest
> I've been able to get)

> 2.  A solid assurance that any conversion that we
> undertake towards Pervasive.SQL 2000 won't be
> wasted by another arbitrary decision - and by
> solid I don't mean some salesman telling me "Oh,
> yeah, we'll never do THAT again!" - I want it in
> writing.

> 3.  Some useful technical assistance in our SQL
> conversion process - most of the time my
> developers find out stuff to tell your support
> people.  We were once informed by one of tech
> people, that when we read in the documentation
> that we could store binary large objects of up to
> 2GB using Pervasive.SQL, and we found out that
> you were actually limited to 32KB, a support
> person told us, quote "Oh, thats a bug in the
> documentation"!!!  Please.  We can take care of
> ourselves, we just need some advice on how best
> to proceed - let us talk to someone who actually
> knows something about your product.

> 4.  Assurance (in writing) that if I buy an
> unlimited distribution license for Pervasive.SQL
> 7, that it will extend to Pervasive.SQL 2000 and
> (to a reasonable extent) whatever comes after
> that.

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Mon, 01 Apr 2002 03:00:00 GMT
 SQL API in P.2000
Hi everyone in this thread!

Say, is there anyone from Pervasive reading this newsgroup?
If yes:
why don't you post your statements here?
If no:
.... very, very poor .......

Christian

P.s.: In the last days we where looking to get away from Pervasive and it
seems
         that we have found an alternative. We are very disapointed about
Pervasive.


Quote:
>Steve,
>Your concerns and problems are similar to our own. We have to stick with
>Pervasive in the short term to get a new release out the door- but we are
>looking really hard at moving away from Pervasive.SQL as soon as possible.

>Every one of their recent announcements (ie. dropping of unlimited
licences,
>dropping 6.15, workstation vs workgroup fiasco, dropping of Scalable SQL)
>has hurt our company financially. With friends like this, who needs
>enemies! - and who knows what's next??  We can't take any more "surprises"
>from Pervasive, which is very disappointing since our company has been
using
>Btrieve in various versions for over 10 years.

>Greg



Mon, 01 Apr 2002 03:00:00 GMT
 SQL API in P.2000

Quote:
> Say, is there anyone from Pervasive reading this newsgroup?

Yes, we're listening, but almost all of us spent all week listening to
over 500 customers who attended our Velocity '99 partners conference in
Austin where many of them voiced similar concerns. Most of us are
extremely tired and behind in e-mail and forums like this right now,
sorry - we're not ignoring you. The conference was very positive and
upbeat and I'm disappointed that all of you on this thread were not
there because I think we have answered almost all the concerns expressed
here. We have certainly made some mistakes and the marketing people who
are resonsible for the worst of those (no peer to peer in Pervasive.SQL
7) mistakes are no longer here plus I think I can honestly say that we
have rectified most of those mistakes. Other decisions like
discontinuing the unlimited distribution license (UDL) and the
ScalableSQL engine may not have been handled well, but were essentially
sound business decisions even though you may not agree with them. I can
also say that if you want to talk to us about it we would be more
than willing to try to meet you half way in rectifying the consequences
of those decisions. The UDL especially was like giving away the keys to
the kingdom, because people shipped hundreds or even thousands of copies
at pennies to the copy without ever bothering to even ship the latest
(free) patches. Then they would often call us up directly to complain of
bugs and performance which resulted in us actually losing money on the
product. This caused further problems and losses of revenue when they
sometimes refused to upgrade to Client/server on installations of 10 to
100 users or more even though it made both technical and economic sense
for everyone.
Technically the SSQL engine can be used with the Pervasive.SQL 2000
product and there has been discussion about providing it to customers to
provide a way to transition to the new relational engine (SRDE). We have
also discussed what to provide to customers in order to make the
transition as easy as possible. I will forward these concerns to our
Director of Developers Solutions, Gary Allison and others. In the


solve these problems and go forward in a much more open and supportive
way. After all we're growing rapidly (that must say something about
the customers that are happy with the products) and the vast majority of
our customers are very happy now with the decisions and directions we
are taking, however, we are human and do make mistakes - especially when
we don't get your feedback. We can't please all the people all the time,
but we are willing to try if you'll call or e-mail us. Also please plan
on attending our conference in the spring of 2001. If you communicate
with us I'll go out on a limb and guarantee that you'll still be a
customer then!

Regards,
John Rothgeb
Systems Engineer, Sales
South Central US

The opinions expressed are my own and not officially those of Pervasive
Software, Inc.

P.S. I plan to go back and answer most of the issues brought up
individually also.

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 03 Apr 2002 03:00:00 GMT
 SQL API in P.2000

Quote:
> I think it's time to put some pressure on Pervasive to rethink the
> decision to drop the native SQL API in P.2000.

Overall the decision has been greeted quite favorably, however, my
personal opinion is that we didn't do nearly enough to find out who was
actaully using the API and make their transition as painless as
possible. In fact we tasked support with turning up customers who used
the API and woudl be affected and couldn't find more than about three at
the time. Of course after we made the decision and droped the API we
found quite a few more and we have worked closely with several of those
to transition their code to ODBC. It is also possible though to just
plug in the Scalable SQL engine to Pervasive.SQL 2000 and use it along
with the new engine (the SRDE) and the Btrieve 7 engine and API. The
real and in my view quite good reason that we dropped SSQL is that it
was a multi-purpose engine and had a reputation of not doing any of it's
three functions (SSQL 3.01, SSQL 4.0, and ODBC) very well. It in fact
usually did not do any of them particularly well until the Pervasive.SQL
7 Service Pack 3, 4, and 5 releases. The fact that there was not a peer
to peer solution on Pervasive.SQL 7 increased the issues as many
customers continued to stay on v6.15 and often didn't bother to pressure
us to provide solutions for their needs (until now) or even threaten to
quit using out products. I can however unequivocably state that we are
completely committed to the Btrieve API (we are looking at XML enabling
it as it's hierarchical nature is particularly well suited to XML unlike
relational technologies) and to a robust and high performance relational
API. Please come to our Developer Solutions Seminars and we'll show you
all the options and features.

Quote:
> We are using the Titan Delphi components for some years now, which are
> quite stable and fast. The query component uses (as I suppose many
> other developers) the native SQL API, and for the moment there is no >
> support for P.2000 because of this.

Several customers have expressed concerns over the Titan components and
thought we tried to work this out with Regatta, we couldn't come to a
mutally agreeable solution so we have just released the Pervasive Direct
Access Components (PDAC), for Inprise Delphi and CBuilder, which does
fully support P.2000

Quote:

> Another point is, that using SQL will result in using ODBC. I don't
> want to think about installing and configuring ODBC on the PCs of our
> customers (or am I wrong in ths point)?

I appreciate your openness and I do believe that you are mistaken here
as we have put in a great deal of work to make the installation and
configuration of the relational components (and the embedding of it in
your application) as seamless as possible.

Quote:
> For me, it seems Pervasive made the second BIG wrong decision in short
> time. The first was the try to drop peer-to-peer with P.SQL. Where
> does Pervasive wants to go?

We want to go back to the future? :-) The fact is that 75% to 90% of our
customers were using the SSQL component as an ODBC engine only and we
invested a great deal of money and resources developing a native ODBC
engine that didn't suffer performance degradation due to having to
translate a proprietary SQL syntax into native ODBC SQL. I'd have to
agree that we didn't do enough to communicate the changes that happened
or to provide a path for easing the transition, but if you'd like to
continue to leverage the performance, scalability, cross platform
openness, and ZDBA features of Pervasive products like Btrieve and it's
successors, then we would like a chance to find a way to make it right
with you.

Quote:
> In a discussion forum on the Titan website (www.reggatta.com) is a
> thread about changing to MS! Is that what Pervasive wants?

Definitely not, but if you think that MS will never drop an API
cruicial to your business then they might really be a better choice than
Pervasive.
Pervasive.SQL 2000 is designed so you can build high performance ODBC
applications (primarily with ADO and/or OleDB so that may not be like
military intelligence :-) which will run against other databases if need
be, as well as leverage features like the Btrieve API, RSI, PDAC,
ActiveX, DTI, JDBC, and Java Class Libraries if you wnat to run on
Pervasive.SQL 2000 across platforms like Windows, NetWare, Linux, and
Solaris.

Quote:

> Looking forward to other opinion,

Hey, we're human and make mistakes from time to time, plus you can't
please all the people all the time. I can say honestly that we do
consistently improve both as a company and our products and we'd like to
talk more to you about how we can make any bumps we put in the road
smoother and avoid things like that in the future. I think the workgroup
solution indicates that we can admit that we make mistakes, but will
rectify them with a superior product if need be. If you give us a chance
I think you'll like what we're doing and the way we are doing it now.

Feel free to call or e-mail us as much as you'd like until we make you
happy. Also please plan on attending our conference in the spring of
2001. If you communicate with us I'll go out on a limb and guarantee
that you'll still be a customer then!

Regards,
John Rothgeb
Systems Engineer, Sales
South Central US

The opinions expressed are my own and not officially those of Pervasive
Software, Inc.

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 03 Apr 2002 03:00:00 GMT
 SQL API in P.2000

Quote:
> I also am worried about the problems of configuring ODBC on customer
PCs -
> can it be a trouble-free process?

Absolutely, it can all be done programatically or with GUI tools and
very easy instructions. We have samples in our SDK for Pervasive.SQL
2000 and if we need to do more just tell us and we will. Gary Allison,

pervasive.com and is very interested in your feedback and issues as well
as in proactively making your lives easier. Please let him and us know
how we can do that. Thanks in advance.

BTW, we've significatly reduced the price of the SDK as well as
enhancing it enormously so please take a look. We give away evals off
the Web site and at our seminars plus I've heard there are also copies
available at developer.novell.com that are worth taking a look at ('nuff
said). Check out the Novell Developer Seminars too since we're giving
lunch talks and one day seminars at those too.

Regards,
John Rothgeb
Systems Engineer, Sales
South Central US

The opinions expressed are my own and not officially those of Pervasive

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 03 Apr 2002 03:00:00 GMT
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. APIs for accessing SQL Server 7.x and SQL Server 2000 transaction log

2. Win API from SQL Server 2000 - Userlist

3. P.SQL 2000 SDK Beta - SQL-API ???

4. Btrieve API woes (in Pervasive.SQL 2000, Btrieve 7.5)

5. Microsoft Access 2000 JDBC API 2.0 driver.

6. Using Open API for building forms in Developer 2000 (Forms 6.0)

7. Designer/2000, API

8. API Function Calls on PVSW 2000

9. Unify 2000 dbdmn API docs

10. PS/SQL for constructing binary tree for pedigree?

11. USING RECORDS IN PS/SQL.


 
Powered by phpBB® Forum Software