I am not good at Rdb.

CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'

should connect to that database.

But it fails with alias already in use.

CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'

works fine, but I have to prefix all table names with "test." and
I do not like that.

What is the correct syntax for:

CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME disk4:[rdb]test'

?

Arne

On 7/21/2022 7:29 PM, Arne Vajhøj wrote:
> I am not good at Rdb.
>
> CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'
>
> should connect to that database.
>
> But it fails with alias already in use.
>
> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'
>
> works fine, but I have to prefix all table names with "test." and
> I do not like that.
>
> What is the correct syntax for:
>
> CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME disk4:[rdb]test'
>
> ?

Now I have come up with:

CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test
SET ALIAS 'test'

Is that the best?

Arne

On 22/07/2022 8:14 am, Arne Vajhøj wrote:
> On 7/21/2022 7:29 PM, Arne Vajhøj wrote:
>> I am not good at Rdb.
>>
>> CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'
>>
>> should connect to that database.
>>
>> But it fails with alias already in use.
>>
>> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'
>>
>> works fine, but I have to prefix all table names with "test." and
>> I do not like that.
>>
>> What is the correct syntax for:
>>
>> CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME disk4:[rdb]test'
>>
>> ?
>
> Now I have come up with:
>
> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test
> SET ALIAS 'test'
>
> Is that the best?
>
> Arne
>
>

Do you need to attach to the database more than once? Have multiple txns
concurrently?

If not just drop the CONNECT. eg: ATTACH 'FILE disk4:[rdb]tes'; IIRC

Den 2022-07-22 kl. 01:29, skrev Arne Vajhøj:
> I am not good at Rdb.
>
> CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'
>
> should connect to that database.
>
> But it fails with alias already in use.

Yes, you probably already have an active attach
which uses the "default connection", and since you
did not specify a new "alias", it tried to use the
same default connection.

>
> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'
>
> works fine, but I have to prefix all table names with "test." and
> I do not like that.
>
> What is the correct syntax for:
>
> CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME disk4:[rdb]test'

If you want a new default connection you need to DISCONNECT the open one.

>
> ?
>
> Arne
>
>

From where are you doing that? Rdb interactive SQL?
Do you need multiple connections? If not, just use
a default connection and only use ATTACH.

I have never used CONNECT, only ATTACH, but otoh usually
only works with one database at a time.

I usually just define sql$database and get an automatic attach.

On 7/21/2022 10:08 PM, Richard Maher wrote:
> On 22/07/2022 8:14 am, Arne Vajhøj wrote:
>> On 7/21/2022 7:29 PM, Arne Vajhøj wrote:
>>> I am not good at Rdb.
>>>
>>> CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'
>>>
>>> should connect to that database.
>>>
>>> But it fails with alias already in use.
>>>
>>> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'
>>>
>>> works fine, but I have to prefix all table names with "test." and
>>> I do not like that.
>>>
>>> What is the correct syntax for:
>>>
>>> CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME
>>> disk4:[rdb]test'
>>>
>>> ?
>>
>> Now I have come up with:
>>
>> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test
>> SET ALIAS 'test'
>>
>> Is that the best?
>
> Do you need to attach to the database more than once? Have multiple txns
> concurrently?
>
> If not just drop the CONNECT. eg: ATTACH 'FILE disk4:[rdb]tes'; IIRC

That worked. Thanks.

Arne

On 7/22/2022 3:35 AM, Jan-Erik Söderholm wrote:
> Den 2022-07-22 kl. 01:29, skrev Arne Vajhøj:
>> I am not good at Rdb.
>>
>> CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'
>>
>> should connect to that database.
>>
>> But it fails with alias already in use.
>
> Yes, you probably already have an active attach
> which uses the "default connection", and since you
> did not specify a new "alias", it tried to use the
> same default connection.

Yes. I just doesn't know where that connection comes from.

>> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'
>>
>> works fine, but I have to prefix all table names with "test." and
>> I do not like that.
>>
>> What is the correct syntax for:
>>
>> CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME disk4:[rdb]test'
>
> If you want a new default connection you need to DISCONNECT the open one.

DISCONNECT did not help.

> From where are you doing that? Rdb interactive SQL?

Program using SQL Services.

> Do you need multiple connections? If not, just use
> a default connection and only use ATTACH.

That works!

:-)

Arne

On Saturday, July 23, 2022 at 1:46:41 AM UTC+10, Arne Vajhøj wrote:
> On 7/22/2022 3:35 AM, Jan-Erik Söderholm wrote:
> > Den 2022-07-22 kl. 01:29, skrev Arne Vajhøj:
> >> I am not good at Rdb.
> >>
> >> CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'
> >>
> >> should connect to that database.
> >>
> >> But it fails with alias already in use.
> >
> > Yes, you probably already have an active attach
> > which uses the "default connection", and since you
> > did not specify a new "alias", it tried to use the
> > same default connection.
> Yes. I just doesn't know where that connection comes from.
> >> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'
> >>
> >> works fine, but I have to prefix all table names with "test." and
> >> I do not like that.
> >>
> >> What is the correct syntax for:
> >>
> >> CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME disk4:[rdb]test'
> >
> > If you want a new default connection you need to DISCONNECT the open one.
> DISCONNECT did not help.
> > From where are you doing that? Rdb interactive SQL?
> Program using SQL Services.
> > Do you need multiple connections? If not, just use
> > a default connection and only use ATTACH.
> That works!
>
> :-)
>
> Arne

I don't have access to RDB anymore so sorry if what I remember is wrong...

I think you used to be able to define a logical SQLINI that points to an initialization file where you can execute SQL commands prior to being dropped into interactive SQL. See if one exists and is pre-defining your db handle

DISCONNECT ALL; from memory is how you can disconnect from all prior attachments/aliases or perhaps DISCONNECT RDB$DBHANDLE ?

Looks like you've solved your issue anyhow, so this post is late to the call

Den 2022-07-24 kl. 18:01, skrev IanD:
> On Saturday, July 23, 2022 at 1:46:41 AM UTC+10, Arne Vajhøj wrote:
>> On 7/22/2022 3:35 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-07-22 kl. 01:29, skrev Arne Vajhøj:
>>>> I am not good at Rdb.
>>>>
>>>> CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'
>>>>
>>>> should connect to that database.
>>>>
>>>> But it fails with alias already in use.
>>>
>>> Yes, you probably already have an active attach
>>> which uses the "default connection", and since you
>>> did not specify a new "alias", it tried to use the
>>> same default connection.
>> Yes. I just doesn't know where that connection comes from.
>>>> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'
>>>>
>>>> works fine, but I have to prefix all table names with "test." and
>>>> I do not like that.
>>>>
>>>> What is the correct syntax for:
>>>>
>>>> CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME disk4:[rdb]test'
>>>
>>> If you want a new default connection you need to DISCONNECT the open one.
>> DISCONNECT did not help.
>>> From where are you doing that? Rdb interactive SQL?
>> Program using SQL Services.
>>> Do you need multiple connections? If not, just use
>>> a default connection and only use ATTACH.
>> That works!
>>
>> :-)
>>
>> Arne
>
>
> I don't have access to RDB anymore so sorry if what I remember is wrong...
>
> I think you used to be able to define a logical SQLINI that points to an initialization file wre you can execute SQL commands prior to being dropped into interactive SQL. See if one exists and is pre-defining your db handle
>
> DISCONNECT ALL; from memory is how you can disconnect from all prior attachments/aliases or perhaps DISCONNECT RDB$DBHANDLE ?
>
> Looks like you've solved your issue anyhow, so this post is late to the call

If you do not have an SQLINI file, or hasn't defined SQL$DATABASE, you
are not connected to any database when entering the SQL interactive CLI.
So you must do:

$ sql
SQL> ATTACH ....
SQL> SELECT ... FROM ...;

The easiest way is to simply define SQL$DATABASE in your LOGiN.COM, in
particluar if you usually access the same database.

SQLINI is usually used to "SET TRANSACTION READ ONLY;" since the default
transaction mode is READ WRITE, and that might give you to much locking
if you usually want to just read things.

When you need to actually update some thing, it is easy to do:

$ def/User sqlini " "
$ sql update ... SET xxx=1234;
$

The empty sqlini definition will only be active in that SQL session.

I ask my developers to try to *never* do:

$ SQL
SQL> select ...
SQL> commit (exit)
$

Since it is very easy to forget that "commit" and lock up things
for the production processes. So always do:

$ sql select ...
$

And you'll get an automatic commit when the select has finished.

You just need to have the SQL$DATABASE logical defined...

Jan-Erik.

On Monday, July 25, 2022 at 5:19:45 AM UTC+10, Jan-Erik Söderholm wrote:
> Den 2022-07-24 kl. 18:01, skrev IanD:
> > On Saturday, July 23, 2022 at 1:46:41 AM UTC+10, Arne Vajhøj wrote:
> >> On 7/22/2022 3:35 AM, Jan-Erik Söderholm wrote:
> >>> Den 2022-07-22 kl. 01:29, skrev Arne Vajhøj:
> >>>> I am not good at Rdb.
> >>>>
> >>>> CONNECT TO 'ATTACH FILENAME disk4:[rdb]test'
> >>>>
> >>>> should connect to that database.
> >>>>
> >>>> But it fails with alias already in use.
> >>>
> >>> Yes, you probably already have an active attach
> >>> which uses the "default connection", and since you
> >>> did not specify a new "alias", it tried to use the
> >>> same default connection.
> >> Yes. I just doesn't know where that connection comes from.
> >>>> CONNECT TO 'ATTACH ALIAS test FILENAME disk4:[rdb]test'
> >>>>
> >>>> works fine, but I have to prefix all table names with "test." and
> >>>> I do not like that.
> >>>>
> >>>> What is the correct syntax for:
> >>>>
> >>>> CONNECT TO 'ATTACH JUSTOVERWRITETHEDEFAULTALIAS FILENAME disk4:[rdb]test'
> >>>
> >>> If you want a new default connection you need to DISCONNECT the open one.
> >> DISCONNECT did not help.
> >>> From where are you doing that? Rdb interactive SQL?
> >> Program using SQL Services.
> >>> Do you need multiple connections? If not, just use
> >>> a default connection and only use ATTACH.
> >> That works!
> >>
> >> :-)
> >>
> >> Arne
> >
> >
> > I don't have access to RDB anymore so sorry if what I remember is wrong....
> >
> > I think you used to be able to define a logical SQLINI that points to an initialization file wre you can execute SQL commands prior to being dropped into interactive SQL. See if one exists and is pre-defining your db handle
> >
> > DISCONNECT ALL; from memory is how you can disconnect from all prior attachments/aliases or perhaps DISCONNECT RDB$DBHANDLE ?
> >
> > Looks like you've solved your issue anyhow, so this post is late to the call
> If you do not have an SQLINI file, or hasn't defined SQL$DATABASE, you
> are not connected to any database when entering the SQL interactive CLI.
> So you must do:
>
> $ sql
> SQL> ATTACH ....
> SQL> SELECT ... FROM ...;
>
> The easiest way is to simply define SQL$DATABASE in your LOGiN.COM, in
> particluar if you usually access the same database.
>
> SQLINI is usually used to "SET TRANSACTION READ ONLY;" since the default
> transaction mode is READ WRITE, and that might give you to much locking
> if you usually want to just read things.
>
> When you need to actually update some thing, it is easy to do:
>
> $ def/User sqlini " "
> $ sql update ... SET xxx=1234;
> $
>
> The empty sqlini definition will only be active in that SQL session.
>
> I ask my developers to try to *never* do:
>
> $ SQL
> SQL> select ...
> SQL> commit (exit)
> $
>
> Since it is very easy to forget that "commit" and lock up things
> for the production processes. So always do:
>
> $ sql select ...
> $
>
> And you'll get an automatic commit when the select has finished.
>
> You just need to have the SQL$DATABASE logical defined...
>
> Jan-Erik.

The point of creating your own definition of SQLINI is to ensure you can start with your own clean slate as it was stated they already had a default connection and they didn't know where it came from

>>> Yes. I just doesn't know where that connection comes from.

Totally agree about the SET TRANS READ ONLY
Not sure why Digital made the default to READ WRITE, not smart from Production environments.

We used to drive everything explicitly through scripts wherever possible rather than rely on expected environment logicals to be there. If developers felt the need to define rdb*m$ logicals then push them through managed scripts. rdb debug flags are an exception of course.

I wonder how fast rdb on x86 hardware will be?

We could never fix the database Page Size on some of our databases as they could not be exported/imported with a new options definition due to their large sizes (some projections calculated we would need more than a two week outage! - that was on an Alpha GS1280 though)

I used to use Oracle trace a lot to nut out performance issues with acms + rdb (if you want to chew through disk space real quick fire up a debug Oracle Trace collection with acms+rdb!).

I even had a crack at rdb expert, not that I could get much sense out of it, our databases exceeded what the product was originally sized to cope for, and after logging a number of tickets to get help, I realised the product was more hype than expert, lol.

What a fantastic product rdb was/is, shame Digital 'gave it away', I wonder if Oracle would ever consider selling it back to VSI ?

It all brings back fond memories...

>>> What a fantastic product rdb was/is, shame Digital 'gave it away', I wonder if Oracle would ever consider selling it back to VSI ?

Now there is an idea....
gt

On 7/24/2022 9:45 PM, IanD wrote:
> I wonder how fast rdb on x86 hardware will be?
>
> We could never fix the database Page Size on some of our databases as
> they could not be exported/imported with a new options definition due
> to their large sizes (some projections calculated we would need more
> than a two week outage! - that was on an Alpha GS1280 though)

A lot of database work is IO bound not CPU bound.

SSD disks would speed up things a lot.

> What a fantastic product rdb was/is, shame Digital 'gave it away', I
> wonder if Oracle would ever consider selling it back to VSI ?

I think it was a big mistake to sell Rdb to Oracle back then.
There were obviously a lot of money to be made.

But today? The VMS market has shrunk a lot. And I suspect
most totally new development would go for MySQL/MariaDB or
PostgreSQL (when it becomes available). Unless Oracle
is willing to sell it cheap then I don't see a good
business case for VSI. And selling cheap is not Larry's
MO.

Arne

> And selling cheap is not Larry's MO.
Buying cheap is... Rdb cost Oracle $US108M, which was made back from license charges in the first 12 months!
The sale was inked 29 years ago (1993), and went through in 1994. Such a sad time at Digital, the 1993 recommendation to the board was for Digital to become a software company with Rdb as the center piece, this was rejected as Rdb had already been sold. Mumble!

Oh well, MariaDB and PostgreSQL for OpenVMS.

gt

On 27/07/2022 1:50 pm, Greg Tinkler wrote:
>> And selling cheap is not Larry's MO.
> Buying cheap is... Rdb cost Oracle $US108M, which was made back from
> license charges in the first 12 months! The sale was inked 29 years
> ago (1993), and went through in 1994. Such a sad time at Digital,
> the 1993 recommendation to the board was for Digital to become a
> software company with Rdb as the center piece, this was rejected as
> Rdb had already been sold. Mumble!
>
> Oh well, MariaDB and PostgreSQL for OpenVMS.
>
> gt

Don't forget that *all* the Rdb "engineers" were gloating about leaving
VMS and going to Windows :-(

Sadly those assassins have eked out a living watching Rdb/VMS flounder

> Don't forget that *all* the Rdb "engineers" were gloating about leaving
> VMS and going to Windows :-(
>
> Sadly those assassins have eked out a living watching Rdb/VMS flounder

SORRY WHAT!!! No they where not.
Yes, they where in the process of porting Rdb on to other platforms, which was the correct business thing to do. At the time was very much looking forward to it, and that it would help drive the OpenVMS sales...

As a group they where collateral damage of the decision by Palmer, and nothing they had a choice in.

The fact that the Rdb group still exists after such a long time is incredible, and due in part that they where probably the best engineering team in Digital at the time, and some of that skill has been used in the main Oracle RDMS toolset...

What we need to focus on now is getting OpenVMS back to where it should be, a fully 64 bit premier secure OS.

OpenVMS floundering has a lot more to do with the lack of engineering foresight and skill over the last 30 years, driven by commercial interests that did not understand the product and wanting to keep the cost low.

gt

On 28/07/2022 7:59 am, Greg Tinkler wrote:
>> Don't forget that *all* the Rdb "engineers" were gloating about leaving
>> VMS and going to Windows :-(
>>
>> Sadly those assassins have eked out a living watching Rdb/VMS flounder
>
> SORRY WHAT!!! No they where not.
> Yes, they where in the process of porting Rdb on to other platforms, which was the correct business thing to do. At the time was very much looking forward to it, and that it would help drive the OpenVMS sales...
>
> As a group they where collateral damage of the decision by Palmer, and nothing they had a choice in.
>
> The fact that the Rdb group still exists after such a long time is incredible, and due in part that they where probably the best engineering team in Digital at the time, and some of that skill has been used in the main Oracle RDMS toolset...
>
> What we need to focus on now is getting OpenVMS back to where it should be, a fully 64 bit premier secure OS.
>
> OpenVMS floundering has a lot more to do with the lack of engineering foresight and skill over the last 30 years, driven by commercial interests that did not understand the product and wanting to keep the cost low.
>
> gt

I beg to differ. My recollection is Rdb/VMS was being considered
technical debt. Before Larry canned Rdb/Windows

> I beg to differ. My recollection is Rdb/VMS was being considered
> technical debt. Before Larry canned Rdb/Windows

'Technical debt' by whom? Larry canned Rdb/Windows (&Unix) as it would have competed against Oracle RDMS...
More interesting is what happened to Rdb*Star :-)) and why.
If you noticed at the time a lot of the Rdb technology/memes where used in the re-engineering of Oracle RDMS.

gt

On 28/07/2022 10:10 am, Greg Tinkler wrote:
>> I beg to differ. My recollection is Rdb/VMS was being considered
>> technical debt. Before Larry canned Rdb/Windows
>
> 'Technical debt' by whom? Larry canned Rdb/Windows (&Unix) as it would have competed against Oracle RDMS...
> More interesting is what happened to Rdb*Star :-)) and why.
> If you noticed at the time a lot of the Rdb technology/memes where used in the re-engineering of Oracle RDMS.
>
> gt
1) Stephen Smith
2) Norm La Stoviva
.. . .

> 1) Stephen Smith
Don't recognize the name.., Ian Smith on the other hand.
> 2) Norm La Stoviva
I assume you mean Norm Lastovica, who did a lot of interesting engineering with Rdb, record caching for one.

So just what do you mean by 'technical debt'?

gt

On 7/27/2022 10:10 PM, Greg Tinkler wrote:
>> I beg to differ. My recollection is Rdb/VMS was being considered
>> technical debt. Before Larry canned Rdb/Windows
>
> 'Technical debt' by whom? Larry canned Rdb/Windows (&Unix) as it would have competed against Oracle RDMS...

The usual explanation is that Oracle could not get any guarantees
that Bliss would continue to be available on Windows so they
dropped Rdb on Windows.

Arne

On 28/07/2022 2:17 pm, Greg Tinkler wrote:
>> 1) Stephen Smith
> Don't recognize the name.., Ian Smith on the other hand.
>> 2) Norm La Stoviva
> I assume you mean Norm Lastovica, who did a lot of interesting engineering with Rdb, record caching for one.
>
> So just what do you mean by 'technical debt'?
>
> gt

Yes, Ian. I slipped with my memory's more recently accessed Cricket ball
tampering Aussie.

By technical debt, I mean "legacy", "mothballed patch only", "on it's
way to being deprecated",

> Yes, Ian. I slipped with my memory's more recently accessed Cricket ball tampering Aussie.
Thought the name was sort of familiar, dam the sand-paper :-]
> By technical debt, I mean "legacy", "mothballed patch only", "on it's way to being deprecated",
That sort of has been the case for almost 30 years, but it is still there, and from a SQL point of view Rdb is in an ok place. Ian has not been backward in adding new features, so not just patch only.
Does the engine need work, yup, as does OpenVMS internals..., and some of the limitations will be because Rdb is limited to OpenVMS. Still the best database engine on OpenVMS.

Besides at $US40k/core Rdb (Oracle) is far too expensive for most sites. Bring back Rdb runtime for free on OpenVMS I say. Won't happen but a nice thought.

gt

On 29/07/2022 10:15 am, Greg Tinkler wrote:
>> Yes, Ian. I slipped with my memory's more recently accessed Cricket ball tampering Aussie.
> Thought the name was sort of familiar, dam the sand-paper :-]
>
>> By technical debt, I mean "legacy", "mothballed patch only", "on it's way to being deprecated",
> That sort of has been the case for almost 30 years, but it is still there, and from a SQL point of view Rdb is in an ok place. Ian has not been backward in adding new features, so not just patch only.
> Does the engine need work, yup, as does OpenVMS internals..., and some of the limitations will be because Rdb is limited to OpenVMS. Still the best database engine on OpenVMS.
>
> Besides at $US40k/core Rdb (Oracle) is far too expensive for most sites. Bring back Rdb runtime for free on OpenVMS I say. Won't happen but a nice thought.
>
> gt

Look, the game's over :-(

Was Rdb technical elegance? Sure!

There's lots to dislike about Orrible Oracle, but shit like Cache
Fusion, RLAC/Fine-Grained security, sheer weight of numbers and SQL
Server is still brilliant.

VGI should have sold their mother to get Oracle continued on VMS!!! :-(

For those of us still dreaming; that my friends, was the death knell.

On 7/29/2022 3:05 AM, Richard Maher wrote:
> On 29/07/2022 10:15 am, Greg Tinkler wrote:
>>> Yes, Ian. I slipped with my memory's more recently accessed Cricket ball
>>> tampering Aussie.
>> Thought the name was sort of familiar, dam the sand-paper :-]
>>
>>> By technical debt, I mean "legacy", "mothballed patch only", "on it's way to
>>> being deprecated",
>> That sort of has been the case for almost 30 years, but it is still there, and
>> from a SQL point of view Rdb is in an ok place. Ian has not been backward in
>> adding new features, so not just patch only.
>> Does the engine need work, yup, as does OpenVMS internals..., and some of the
>> limitations will be because Rdb is limited to OpenVMS. Still the best
>> database engine on OpenVMS.
>>
>> Besides at $US40k/core Rdb (Oracle) is far too expensive for most sites.
>> Bring back Rdb runtime for free on OpenVMS I say. Won't happen but a nice
>> thought.
>>
>> gt
>
> Look, the game's over :-(
>
> Was Rdb technical elegance? Sure!
>
> There's lots to dislike about Orrible Oracle, but shit like Cache Fusion,
> RLAC/Fine-Grained security, sheer weight of numbers and SQL Server is still
> brilliant.
>
> VGI should have sold their mother to get Oracle continued on VMS!!! :-(
>
> For those of us still dreaming; that my friends, was the death knell.

I partly understand, but, I still have to ask, why when there is a personal
"death knell", that person then extends it to everyone else?

Yeah, one can go on and on about some nice product/feature, but that does not
mean that everyone uses it.

I've never used Rdb, nor Oracle. I've produced some fine (in my opinion)
applications over the years, and the only opinion that matters is the customer's
opinion, and I've had some very satisfied customers.

So Richard, I'm sorry for you that you do not have what you wish for, but just
because your boat is sinking doesn't mean that the whole planet is in your boat.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-07-29, Dave Froble <davef@tsoft-inc.com> wrote:
> On 7/29/2022 3:05 AM, Richard Maher wrote:
>>
>> VGI should have sold their mother to get Oracle continued on VMS!!! :-(
>>
>> For those of us still dreaming; that my friends, was the death knell.
>
> I partly understand, but, I still have to ask, why when there is a personal
> "death knell", that person then extends it to everyone else?
>

Because while you might be comfy in your own little world, you only get
to play in that world because there's enough people doing other things
that makes it profitable enough for VSI to continue making software for
you to play with.

> Yeah, one can go on and on about some nice product/feature, but that does not
> mean that everyone uses it.
>

Losing enough major third-party applications can be the difference
between a port to x86-64 being viable and not being viable.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 7/29/2022 1:40 PM, Simon Clubley wrote:
> On 2022-07-29, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 7/29/2022 3:05 AM, Richard Maher wrote:
>>>
>>> VGI should have sold their mother to get Oracle continued on VMS!!! :-(
>>>
>>> For those of us still dreaming; that my friends, was the death knell.
>>
>> I partly understand, but, I still have to ask, why when there is a personal
>> "death knell", that person then extends it to everyone else?
>>
>
> Because while you might be comfy in your own little world, you only get
> to play in that world because there's enough people doing other things
> that makes it profitable enough for VSI to continue making software for
> you to play with.

Just as Richard has done, you're making assumptions Simon. Now, if you had any
facts, numbers, and such to support your statement ...

>> Yeah, one can go on and on about some nice product/feature, but that does not
>> mean that everyone uses it.
>>
>
> Losing enough major third-party applications can be the difference
> between a port to x86-64 being viable and not being viable.
>
> Simon.
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486