 | |
Migration from native Btrieve calls to SQL with ZEOS components
comp.databases.btrieve comp.databases.btrieve
 |
| | Thread Tools | Display Modes |
#11
 
| ||||||
| ||||||
|
Re: Migration from native Btrieve calls to SQL with ZEOS components -
02-26-2008
, 02:16 AM
|
This is a very unusual approach. What kind of application is this for? There are several applications for a process optimization system fo |
(vulcanisation).
Quote:
|
I just cannot fathom why a new database would be needed every month. There are two facts why we need new (small) databases: |
Some Customers want to keep the information on CD-ROM. Ok, saving on CD
and deleting old records is a possibility.
Batch database:
The rubber compound is made by the supplier batch by batch of about 200
kg. More than batch per shift and machine is needed. Each batch is
slightly different, so batch characterisic is taken in account to
optimize quality an cycletime of the machines. So you have a lott of
batch data records wich are partially needed at offline-systems whitout
network access. So they are transported by USB-Stick.
Quote:
|
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 Most users know nearly nothing about database, Btrieve, Pervasive and so |
Quote:
|
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. At our Customers we have nearly every version from 6.15 to 9.5. |
Quote:
|
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. ACK |
are process application engineers. Databases are "only" tools for us.
Quote:
|
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... Thanks a lot! |
Axel
#12
| ||||||
| ||||||
|
|
This is a very unusual approach. What kind of application is this for? There are several applications for a process optimization system fo |
(vulcanisation).
Quote:
|
I just cannot fathom why a new database would be needed every month. There are two facts why we need new (small) databases: |
Some Customers want to keep the information on CD-ROM. Ok, saving on CD
and deleting old records is a possibility.
Batch database:
The rubber compound is made by the supplier batch by batch of about 200
kg. More than batch per shift and machine is needed. Each batch is
slightly different, so batch characterisic is taken in account to
optimize quality an cycletime of the machines. So you have a lott of
batch data records wich are partially needed at offline-systems whitout
network access. So they are transported by USB-Stick.
Quote:
|
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 Most users know nearly nothing about database, Btrieve, Pervasive and so |
Quote:
|
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. At our Customers we have nearly every version from 6.15 to 9.5. |
Quote:
|
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. ACK |
are process application engineers. Databases are "only" tools for us.
Quote:
|
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... Thanks a lot! |
Axel
#13
| ||||||
| ||||||
|
|
This is a very unusual approach. What kind of application is this for? There are several applications for a process optimization system fo |
(vulcanisation).
Quote:
|
I just cannot fathom why a new database would be needed every month. There are two facts why we need new (small) databases: |
Some Customers want to keep the information on CD-ROM. Ok, saving on CD
and deleting old records is a possibility.
Batch database:
The rubber compound is made by the supplier batch by batch of about 200
kg. More than batch per shift and machine is needed. Each batch is
slightly different, so batch characterisic is taken in account to
optimize quality an cycletime of the machines. So you have a lott of
batch data records wich are partially needed at offline-systems whitout
network access. So they are transported by USB-Stick.
Quote:
|
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 Most users know nearly nothing about database, Btrieve, Pervasive and so |
Quote:
|
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. At our Customers we have nearly every version from 6.15 to 9.5. |
Quote:
|
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. ACK |
are process application engineers. Databases are "only" tools for us.
Quote:
|
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... Thanks a lot! |
Axel
#14
| |||
| |||
|
|
Bill, Bill Bach wrote: This is a very unusual approach. What kind of application is this for? There are several applications for a process optimization system fo rubber injection moulding machines. Its calculating state of cure (vulcanisation). I just cannot fathom why a new database would be needed every month. There are two facts why we need new (small) databases: documentation: Some Customers want to keep the information on CD-ROM. Ok, saving on CD and deleting old records is a possibility. Batch database: The rubber compound is made by the supplier batch by batch of about 200 kg. More than batch per shift and machine is needed. Each batch is slightly different, so batch characterisic is taken in account to optimize quality an cycletime of the machines. So you have a lott of batch data records wich are partially needed at offline-systems whitout network access. So they are transported by USB-Stick. 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 Most users know nearly nothing about database, Btrieve, Pervasive and so on. It has to work. And it works very well. 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. At our Customers we have nearly every version from 6.15 to 9.5. It is clear, that 6.15 will not work with SQL. 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. ACK And this is also true for us. We are not the IT and database freeks. We are process application engineers. Databases are "only" tools for us. 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... Thanks a lot! I will try that. Axel |
--
#15
| |||
| |||
|
|
Bill, Bill Bach wrote: This is a very unusual approach. What kind of application is this for? There are several applications for a process optimization system fo rubber injection moulding machines. Its calculating state of cure (vulcanisation). I just cannot fathom why a new database would be needed every month. There are two facts why we need new (small) databases: documentation: Some Customers want to keep the information on CD-ROM. Ok, saving on CD and deleting old records is a possibility. Batch database: The rubber compound is made by the supplier batch by batch of about 200 kg. More than batch per shift and machine is needed. Each batch is slightly different, so batch characterisic is taken in account to optimize quality an cycletime of the machines. So you have a lott of batch data records wich are partially needed at offline-systems whitout network access. So they are transported by USB-Stick. 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 Most users know nearly nothing about database, Btrieve, Pervasive and so on. It has to work. And it works very well. 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. At our Customers we have nearly every version from 6.15 to 9.5. It is clear, that 6.15 will not work with SQL. 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. ACK And this is also true for us. We are not the IT and database freeks. We are process application engineers. Databases are "only" tools for us. 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... Thanks a lot! I will try that. Axel |
--
#16
| |||
| |||
|
|
Bill, Bill Bach wrote: This is a very unusual approach. What kind of application is this for? There are several applications for a process optimization system fo rubber injection moulding machines. Its calculating state of cure (vulcanisation). I just cannot fathom why a new database would be needed every month. There are two facts why we need new (small) databases: documentation: Some Customers want to keep the information on CD-ROM. Ok, saving on CD and deleting old records is a possibility. Batch database: The rubber compound is made by the supplier batch by batch of about 200 kg. More than batch per shift and machine is needed. Each batch is slightly different, so batch characterisic is taken in account to optimize quality an cycletime of the machines. So you have a lott of batch data records wich are partially needed at offline-systems whitout network access. So they are transported by USB-Stick. 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 Most users know nearly nothing about database, Btrieve, Pervasive and so on. It has to work. And it works very well. 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. At our Customers we have nearly every version from 6.15 to 9.5. It is clear, that 6.15 will not work with SQL. 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. ACK And this is also true for us. We are not the IT and database freeks. We are process application engineers. Databases are "only" tools for us. 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... Thanks a lot! I will try that. Axel |
--
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.