Migration from native Btrieve calls to SQL with ZEOS components

#1

Hello,

we want to migrate our applications to SQL. Until now we use as a relict
of DOS times native Btrieve calls.

We work in this way now:
* LogIn as Administrator
* Start Pervasive Control-Center
* create an new database
* LogOut as Administrator an LogIn as User
* Work with our application.

This is noch acceptable for our users in two points:
* They have no Administrator rights.
* They don't want to be bored with the Controlcenter.

How can we create and use a dateabase at runtime of our Application.
It can be done easily with Firebird/Interbase by the ZEOS components we
uses.
How can we do this with Pervasive.SQL e.g. via ADO protocol.

Axel

#2

Native Btrieve calls are not a relic of days past -- in fact, they
provide an ultra-fast interface directly into a transactional database
that can ALSO be used as a relational database from SQL/ODBC (and ADO).

You should be able to run your old DOS applications directly on any
newer Win32 environment if you are using Pervasive.SQL with no extra
steps.

As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

Creating a database is an administrative task that does require
administrative rights. As such, even if you used the DTI or DTO
interfaces to create a new database in the envirnment, you would either
need to provide an administrative login inside the application (which
is a security risk), or you'd have to prompt for a login name at the
time the code runs, and users would still need it.

Can you be more specific about your actual versions and provide a
reason why the users need to keep creating new databases?
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***

Axel Potthoff wrote:

Quote:

Hello,

we want to migrate our applications to SQL. Until now we use as a
relict of DOS times native Btrieve calls.

We work in this way now:
* LogIn as Administrator
* Start Pervasive Control-Center
* create an new database
* LogOut as Administrator an LogIn as User
* Work with our application.

This is noch acceptable for our users in two points:
* They have no Administrator rights.
* They don't want to be bored with the Controlcenter.

How can we create and use a dateabase at runtime of our Application.
It can be done easily with Firebird/Interbase by the ZEOS components
we uses.
How can we do this with Pervasive.SQL e.g. via ADO protocol.

Axel

--

#3

Native Btrieve calls are not a relic of days past -- in fact, they
provide an ultra-fast interface directly into a transactional database
that can ALSO be used as a relational database from SQL/ODBC (and ADO).

You should be able to run your old DOS applications directly on any
newer Win32 environment if you are using Pervasive.SQL with no extra
steps.

As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

Creating a database is an administrative task that does require
administrative rights. As such, even if you used the DTI or DTO
interfaces to create a new database in the envirnment, you would either
need to provide an administrative login inside the application (which
is a security risk), or you'd have to prompt for a login name at the
time the code runs, and users would still need it.

Can you be more specific about your actual versions and provide a
reason why the users need to keep creating new databases?
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***

Axel Potthoff wrote:

Quote:

Hello,

we want to migrate our applications to SQL. Until now we use as a
relict of DOS times native Btrieve calls.

We work in this way now:
* LogIn as Administrator
* Start Pervasive Control-Center
* create an new database
* LogOut as Administrator an LogIn as User
* Work with our application.

This is noch acceptable for our users in two points:
* They have no Administrator rights.
* They don't want to be bored with the Controlcenter.

How can we create and use a dateabase at runtime of our Application.
It can be done easily with Firebird/Interbase by the ZEOS components
we uses.
How can we do this with Pervasive.SQL e.g. via ADO protocol.

Axel

--

#4

Native Btrieve calls are not a relic of days past -- in fact, they
provide an ultra-fast interface directly into a transactional database
that can ALSO be used as a relational database from SQL/ODBC (and ADO).

You should be able to run your old DOS applications directly on any
newer Win32 environment if you are using Pervasive.SQL with no extra
steps.

As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

Creating a database is an administrative task that does require
administrative rights. As such, even if you used the DTI or DTO
interfaces to create a new database in the envirnment, you would either
need to provide an administrative login inside the application (which
is a security risk), or you'd have to prompt for a login name at the
time the code runs, and users would still need it.

Can you be more specific about your actual versions and provide a
reason why the users need to keep creating new databases?
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***

Axel Potthoff wrote:

Quote:

Hello,

we want to migrate our applications to SQL. Until now we use as a
relict of DOS times native Btrieve calls.

We work in this way now:
* LogIn as Administrator
* Start Pervasive Control-Center
* create an new database
* LogOut as Administrator an LogIn as User
* Work with our application.

This is noch acceptable for our users in two points:
* They have no Administrator rights.
* They don't want to be bored with the Controlcenter.

How can we create and use a dateabase at runtime of our Application.
It can be done easily with Firebird/Interbase by the ZEOS components
we uses.
How can we do this with Pervasive.SQL e.g. via ADO protocol.

Axel

--

#5

Bill,

I have to explain my basic problem a little more:
We have no DOS applications any more. We do Btrieve calls in Windows.
We don't use DDF files until now.
We use local workstation engines. Our customers don't like someone,
installing something on their server.
But we want to change to SQL do be more flexible to changes in the
structure.

Bill Bach wrote:

Quote:

...
As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

We started with Btrieve 5.15.
The users do this since 15 years or more.
They say, "The month is over, let us start with an new data file for
documentation."
They take the data file, put it to a USB stick an read data records at
an offline system.
With native Btrieve this all was no problem. "One file = one table". A
simple call of function 14 and you have an new data file. The structure
is made by our application, but filename and location can be choosen
freely by the user. We have not had any problems in the past.
And that is all what we want.
But now, the controlcenter has to be used. You are right, that is
nothing for the user! And the controlcenter writes something to the
C:\WINDOWS\DBNAMES.CFG and maybe elsewhere before I can connect the
datafiles.

Is there no simpler solution?

Axel

#6

Bill,

I have to explain my basic problem a little more:
We have no DOS applications any more. We do Btrieve calls in Windows.
We don't use DDF files until now.
We use local workstation engines. Our customers don't like someone,
installing something on their server.
But we want to change to SQL do be more flexible to changes in the
structure.

Bill Bach wrote:

Quote:

...
As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

We started with Btrieve 5.15.
The users do this since 15 years or more.
They say, "The month is over, let us start with an new data file for
documentation."
They take the data file, put it to a USB stick an read data records at
an offline system.
With native Btrieve this all was no problem. "One file = one table". A
simple call of function 14 and you have an new data file. The structure
is made by our application, but filename and location can be choosen
freely by the user. We have not had any problems in the past.
And that is all what we want.
But now, the controlcenter has to be used. You are right, that is
nothing for the user! And the controlcenter writes something to the
C:\WINDOWS\DBNAMES.CFG and maybe elsewhere before I can connect the
datafiles.

Is there no simpler solution?

Axel

#7

Bill,

I have to explain my basic problem a little more:
We have no DOS applications any more. We do Btrieve calls in Windows.
We don't use DDF files until now.
We use local workstation engines. Our customers don't like someone,
installing something on their server.
But we want to change to SQL do be more flexible to changes in the
structure.

Bill Bach wrote:

Quote:

...
As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

We started with Btrieve 5.15.
The users do this since 15 years or more.
They say, "The month is over, let us start with an new data file for
documentation."
They take the data file, put it to a USB stick an read data records at
an offline system.
With native Btrieve this all was no problem. "One file = one table". A
simple call of function 14 and you have an new data file. The structure
is made by our application, but filename and location can be choosen
freely by the user. We have not had any problems in the past.
And that is all what we want.
But now, the controlcenter has to be used. You are right, that is
nothing for the user! And the controlcenter writes something to the
C:\WINDOWS\DBNAMES.CFG and maybe elsewhere before I can connect the
datafiles.

Is there no simpler solution?

Axel

#8

This is a very unusual approach. What kind of application is this for?
I just cannot fathom why a new database would be needed every month.
This makes accessing history a LOT more difficult than it should be,
and users may be doing this simple because they do not know any better
way

What exact database version are you using? Obviously it is PSQL2000i
or newer, since the PCC was introduced in that version, but it could be
PSQLV8, PSQLv9, or PSQLv10, and the capabilities may vary between
versions.

As for not wanting software on the server, then it is clear that your
customers also do not understand the benefits of client/server
capabilities, and the stability and performance gains that it offers on
any multi-user system.

If they really want to continue (and I recommend against it), then
you'll have to have some tricks up your sleeve. You can use the modern
Distributed Tuning Objects (DTO) calls to create the database for your
user, using something like this (copied from the manual):

Dim result As dtoResult
Dim database As DtoDatabase
Set database = New DtoDatabase
' Set properties for new database
database.Name = "MYDATABASE"
database.DdfPath = "C:\test"
database.DataPath = "C:\test"
database.Flags = dtoDbFlagCreateDDF + dtoDbFlagRI
result = my_session.Databases.Add(database)
If NOT result = Dto_Success Then
MsgBox "Error"+ Session.Error(result)
End If

Of course, you must also connect to the server and provide a valid
username/password before running this script. If you are ONLY using
Workgroup Engines, though, then you do NOT need a password, as the WGE
does NOT implement database security at all. In short, you can provide
"Administrator" and no password, and a WGE will allow you in.

See the DTO documentation (provided with the product) for more detailed
information. On older systems, you may need an additional DTO
installation, although PSQLv10 systems should be fine...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***

Axel Potthoff wrote:

Quote:

Bill,

I have to explain my basic problem a little more:
We have no DOS applications any more. We do Btrieve calls in Windows.
We don't use DDF files until now.
We use local workstation engines. Our customers don't like someone,
installing something on their server.
But we want to change to SQL do be more flexible to changes in the
structure.

Bill Bach wrote:
...
As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

We started with Btrieve 5.15.
The users do this since 15 years or more.
They say, "The month is over, let us start with an new data file for
documentation."
They take the data file, put it to a USB stick an read data records at
an offline system.
With native Btrieve this all was no problem. "One file = one table". A
simple call of function 14 and you have an new data file. The
structure is made by our application, but filename and location can
be choosen freely by the user. We have not had any problems in the
past. And that is all what we want.
But now, the controlcenter has to be used. You are right, that is
nothing for the user! And the controlcenter writes something to the
C:\WINDOWS\DBNAMES.CFG and maybe elsewhere before I can connect the
datafiles.

Is there no simpler solution?

Axel

--

#9

This is a very unusual approach. What kind of application is this for?
I just cannot fathom why a new database would be needed every month.
This makes accessing history a LOT more difficult than it should be,
and users may be doing this simple because they do not know any better
way

What exact database version are you using? Obviously it is PSQL2000i
or newer, since the PCC was introduced in that version, but it could be
PSQLV8, PSQLv9, or PSQLv10, and the capabilities may vary between
versions.

As for not wanting software on the server, then it is clear that your
customers also do not understand the benefits of client/server
capabilities, and the stability and performance gains that it offers on
any multi-user system.

If they really want to continue (and I recommend against it), then
you'll have to have some tricks up your sleeve. You can use the modern
Distributed Tuning Objects (DTO) calls to create the database for your
user, using something like this (copied from the manual):

Dim result As dtoResult
Dim database As DtoDatabase
Set database = New DtoDatabase
' Set properties for new database
database.Name = "MYDATABASE"
database.DdfPath = "C:\test"
database.DataPath = "C:\test"
database.Flags = dtoDbFlagCreateDDF + dtoDbFlagRI
result = my_session.Databases.Add(database)
If NOT result = Dto_Success Then
MsgBox "Error"+ Session.Error(result)
End If

Of course, you must also connect to the server and provide a valid
username/password before running this script. If you are ONLY using
Workgroup Engines, though, then you do NOT need a password, as the WGE
does NOT implement database security at all. In short, you can provide
"Administrator" and no password, and a WGE will allow you in.

See the DTO documentation (provided with the product) for more detailed
information. On older systems, you may need an additional DTO
installation, although PSQLv10 systems should be fine...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***

Axel Potthoff wrote:

Quote:

Bill,

I have to explain my basic problem a little more:
We have no DOS applications any more. We do Btrieve calls in Windows.
We don't use DDF files until now.
We use local workstation engines. Our customers don't like someone,
installing something on their server.
But we want to change to SQL do be more flexible to changes in the
structure.

Bill Bach wrote:
...
As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

We started with Btrieve 5.15.
The users do this since 15 years or more.
They say, "The month is over, let us start with an new data file for
documentation."
They take the data file, put it to a USB stick an read data records at
an offline system.
With native Btrieve this all was no problem. "One file = one table". A
simple call of function 14 and you have an new data file. The
structure is made by our application, but filename and location can
be choosen freely by the user. We have not had any problems in the
past. And that is all what we want.
But now, the controlcenter has to be used. You are right, that is
nothing for the user! And the controlcenter writes something to the
C:\WINDOWS\DBNAMES.CFG and maybe elsewhere before I can connect the
datafiles.

Is there no simpler solution?

Axel

--

#10

This is a very unusual approach. What kind of application is this for?
I just cannot fathom why a new database would be needed every month.
This makes accessing history a LOT more difficult than it should be,
and users may be doing this simple because they do not know any better
way

What exact database version are you using? Obviously it is PSQL2000i
or newer, since the PCC was introduced in that version, but it could be
PSQLV8, PSQLv9, or PSQLv10, and the capabilities may vary between
versions.

As for not wanting software on the server, then it is clear that your
customers also do not understand the benefits of client/server
capabilities, and the stability and performance gains that it offers on
any multi-user system.

If they really want to continue (and I recommend against it), then
you'll have to have some tricks up your sleeve. You can use the modern
Distributed Tuning Objects (DTO) calls to create the database for your
user, using something like this (copied from the manual):

Dim result As dtoResult
Dim database As DtoDatabase
Set database = New DtoDatabase
' Set properties for new database
database.Name = "MYDATABASE"
database.DdfPath = "C:\test"
database.DataPath = "C:\test"
database.Flags = dtoDbFlagCreateDDF + dtoDbFlagRI
result = my_session.Databases.Add(database)
If NOT result = Dto_Success Then
MsgBox "Error"+ Session.Error(result)
End If

Of course, you must also connect to the server and provide a valid
username/password before running this script. If you are ONLY using
Workgroup Engines, though, then you do NOT need a password, as the WGE
does NOT implement database security at all. In short, you can provide
"Administrator" and no password, and a WGE will allow you in.

See the DTO documentation (provided with the product) for more detailed
information. On older systems, you may need an additional DTO
installation, although PSQLv10 systems should be fine...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - March 2008 ***

Axel Potthoff wrote:

Quote:

Bill,

I have to explain my basic problem a little more:
We have no DOS applications any more. We do Btrieve calls in Windows.
We don't use DDF files until now.
We use local workstation engines. Our customers don't like someone,
installing something on their server.
But we want to change to SQL do be more flexible to changes in the
structure.

Bill Bach wrote:
...
As for your "new" ADO application -- why are the users creating
databases? The users should be accessing databases created by the
developers and/or database administrator, and they should not be
creating new ones.

We started with Btrieve 5.15.
The users do this since 15 years or more.
They say, "The month is over, let us start with an new data file for
documentation."
They take the data file, put it to a USB stick an read data records at
an offline system.
With native Btrieve this all was no problem. "One file = one table". A
simple call of function 14 and you have an new data file. The
structure is made by our application, but filename and location can
be choosen freely by the user. We have not had any problems in the
past. And that is all what we want.
But now, the controlcenter has to be used. You are right, that is
nothing for the user! And the controlcenter writes something to the
C:\WINDOWS\DBNAMES.CFG and maybe elsewhere before I can connect the
datafiles.

Is there no simpler solution?

Axel

--

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Migration from native Btrieve calls to SQL with ZEOS components

comp.databases.btrieve comp.databases.btrieve

Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 02:48 AM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 08:03 AM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 08:03 AM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 08:03 AM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 09:48 AM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 09:48 AM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 09:48 AM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 02:21 PM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 02:21 PM

Re: Migration from native Btrieve calls to SQL with ZEOS components - 02-25-2008 , 02:21 PM