🚀 go-pugleaf

"PeaShooter_OMO" <me@me.com> wrote in
news:456abc46@newsgroups.borland.com: 

> Good day
> 
> I am looking for a FreeWare/OpenSource Interbase that is stable and
> fast. Which one is the best.
> 
> Thank you 
> 
> 
> 

there is not an open source interbase that is mantained
any more. It has been forked to Firebird and the commercial
interbase. 

Regards
Yannis.

PeaShooter_OMO wrote:

> I am looking for a FreeWare/OpenSource Interbase that is stable and
> fast. Which one is the best.

	The only stable versions of IB Open Edition are 6.0.1.6 and 6.0.2.0.
Neither one are actively supported, and neither one are as fast as
current IB commercial editions.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
How to ask questions the smart way:
  http://www.catb.org/~esr/faqs/smart-questions.html

The latest versions of IB (7.5 and the new 8.0) are amazing in OLTP 
environments. You have good SMP support, embedded users authentication, 
which is great for ISV's, and a host of other features not found in Open 
Source IB or Firebird.

If you absolutely can't afford to license IB, then use Firebird 2.0.

Loren

If I understand the licensing fees, with a three computer system, it 
would cost us $3,200 to license InterBase 7+.  Is this about right?  If 
so, as a small business, it prices us right out of the marketplace.

Jack Mason wrote:
> If I understand the licensing fees, with a three computer system, it 
> would cost us $3,200 to license InterBase 7+.  Is this about right?  If 
> so, as a small business, it prices us right out of the marketplace.

I don't believe that is correct. The server license is several hundred 
dollars (and allows, I think, up to four connections), and about $150 
for each client license, with 10-packs available at a discount. Don't 
quote me on the exact numbers, but it's very affordable, especially if 
you need the dozen or so major features that FB doesn't have. Don't get 
me wrong, I love the new Firebird 2.0 release, but it still doesn't have 
some of IB's best features, and it takes the FB team a couple years to 
finish each round of new features.

Check out page 15 of this link:

http://www.borland.com/resources/en/pdf/white_papers/ib_vs_SQLServer.pdf

IMHO, there are only 2 databases in the world: IB/FB and Oracle. IB/FB 
work extremely well for about 98% of the projects most people are 
involved in, and for the others, there's Oracle. SQL Server just barely 
released their first version (2005) that supports row versioning, and it 
is turned off by default. If you read articles about the feature, there 
are warnings to only turn it on if you really need it. IB/FB and Oracle 
have had row versioning perfected for ages.

My $0.02.

Loren

Loren Szendre wrote:

> Jack Mason wrote:
> > If I understand the licensing fees, with a three computer system,
> > it  would cost us $3,200 to license InterBase 7+.  Is this about
> > right?  If  so, as a small business, it prices us right out of the
> > marketplace.
> 
> I don't believe that is correct. The server license is several
> hundred dollars (and allows, I think, up to four connections), and
> about $150 for each client license, with 10-packs available at a
> discount.

	It isn't clear what Jack means by a "three computer system," but
presuming he means a three *user* system (whether the users connect to
the server locally or from client workstations is not relevant to
licensing costs), the cost would be:

Server + 1 user license: $200
2 addtional users: $300

	...so the total cost is $500 in this case. 

	If he wanted three copies of desktop edition (for local-only
connectivity on three separate, un-linked databases), it would cost
$180.

	I'm not sure where the $3200 number came from, but it's *way* out of
line.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Everything You Need to Know About InterBase Character Sets:
  http://blogs.teamb.com/craigstuntz/articles/403.aspx

Jack Mason wrote:
> If I understand the licensing fees, with a three computer system, it 
> would cost us $3,200 to license InterBase 7+.  Is this about right?  If 
> so, as a small business, it prices us right out of the marketplace.

I just put in a 4 user IB system -- on a Dual Core AMD 64 running 
OpenSuse -- Novell Enterprise Server -- Just one server License -- Less 
than/around $700  I think -- don't recall exactly -- but it didn't cause 
a ripple on the system budget even. Less than the Novell with update 
protection -- that's for sure!



-- 
Will R
PMC Consulting

Thanks, Loren.  I had seen the white paper comparing IB and SQL Server. 
  What I was looking for was FireBird vs. IB.  I don't believe we use 
many features of IB, just the basics.  We needed a server based database 
to replace an old Borland database system and IB with IB Objects got us 
there the easiest.  [There is a bug in IB Objects in the RECORDCOUNT 
procedure (a wayward pointer, possibly) that gives us grief and we have 
to restart our applications at least weekly, but that is a separate issue.]

We did not know enough, or care enough, about databases to be dangerous 
and just needed to be able to convert from Paradox as easily and quickly 
as possible.

The only reason we are even actively interested in changing from IB 
6.0.2.0 is that we are beginning to use the new dual core processors and 
our IB doesn't work on those without using the IBAffinity program.  We 
have been using the same version for about 5 years or more and it could 
be time for us to upgrade.

Is there a comparison between IB and Firebird somewhere?

Thanks

Jack,

As you know, IB and FB have parted ways. With the release of FB 2.0, it 
would be unwise to use IBX to access FB 2.0, even though I imagine there 
are folks out there trying it.

I don't know about any papers comparing the two, but I can tell you that 
if you need SMP support, Embedded User Authentication, Advanced Logging 
capabilities (as well as some other features to enable using IB in 
larger Enterprise environments) -- then you should use IB over FB.

FB 2.0 is like the old open source version of IB on steroids -- lots of 
bugfixes, gobs of new features and more built-in functions, and lots of 
limitations removed. But it still can't handle SMP and doesn't have EUA, 
and a few other features.

Bottom line -- both have features and capabilities that the other 
doesn't have. I can't tell you which is better for you. You have to 
decide where your pricepoint is, and what features are important to your 
business. I can tell you that long-term the cost difference will be 
inconsequential. So choose the one that fits your needs the best -- in 
the long run that will be the least expensive choice.

Loren

Loren,

> As you know, IB and FB have parted ways. With the release of FB 2.0, it 
> would be unwise to use IBX to access FB 2.0, even though I imagine there 
> are folks out there trying it.
> 
> I don't know about any papers comparing the two, but I can tell you that 
> if you need SMP support, Embedded User Authentication, Advanced Logging 
> capabilities (as well as some other features to enable using IB in 
> larger Enterprise environments) -- then you should use IB over FB.
> 
> FB 2.0 is like the old open source version of IB on steroids -- lots of 
> bugfixes, gobs of new features and more built-in functions, and lots of 
> limitations removed. But it still can't handle SMP and doesn't have EUA, 
> and a few other features.

The Classic architecture handles SMP just fine. Embedded User 
Authentication isn't available. Yet. I don't want to get into details 
what's new in Firebird 2.0, because the Release notes document is > 150 
pages long. ;-)

> Bottom line -- both have features and capabilities that the other 
> doesn't have.

Right. It's a matter of personal requirements. One needs to write them 
down, evaluate, etc.





-- 
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com

Thomas Steinmaurer wrote:

> The Classic architecture handles SMP just fine.

	Along with all of the limitations classic has always had -- no shared
cache, dicey security, etc. Borland stopped developing classic for a
reason, and it looks to me like Firebird is going the same path for the
most part.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio Gonz�lez has a new CD of 
  Irish music out, and it's good: http://tinyurl.com/7hgfr

Thomas Steinmaurer wrote:

> The Classic architecture handles SMP just fine.

It also does not scale well. Try running classic with two to three hundred concurrent users. Jim Starkey wrote a detailed explanation of why classic does not scale well on the Firebird support list about a year ago IIRC.

--
Bill Todd (TeamB)

Bill Todd wrote:
> Thomas Steinmaurer wrote:
> 
>> The Classic architecture handles SMP just fine.
> 
> It also does not scale well. Try running classic with two to three hundred concurrent users. Jim Starkey wrote a detailed explanation of why classic does not scale well on the Firebird support list about a year ago IIRC.
> 

If Mr. Mason has a "three computer system", I wouldn't think a scaling 
problem will hit him in the near future.


-- 
Aage J.

I certainly agree with that. With the little bit of information available it is likely that any client/server database would work and that includes PostgreSQL and Firebird if he wants to use an open source database. To know what the best choices are we would need to know a lot more about his requirements.

--
Bill Todd (TeamB)

Thomas Steinmaurer wrote:
> 
> The Classic architecture handles SMP just fine. 

Not according to Jim Starkey, the original architect of InterBase -

"I understand you you're saying, particularly since I designed it that way.  But 
classic doesn't scale well for update intensive applications, doesn't meet 
contemporary standards for robustness, and has unenforceable security.  If you 
are looking for an existence proof, yes, it does run on SMP, but not in a manner 
  attractive to new users."

-- 
Jeff Overcash (TeamB)
       (Please do not email me directly unless  asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly.  Specialization is for 
insects.   (RAH)

>> The Classic architecture handles SMP just fine. 
> 
> Not according to Jim Starkey, the original architect of InterBase -
> 
> "I understand you you're saying, particularly since I designed it that 
> way.  But classic doesn't scale well for update intensive applications, 
> doesn't meet contemporary standards for robustness, and has 
> unenforceable security.  If you are looking for an existence proof, yes, 
> it does run on SMP, but not in a manner  attractive to new users."

You guys are reading the Firebird lists? Excellent! ;-)

Care to keep IBX compatible with Firebird? You would do a "few" Delphi 
users with IBX legacy apps a favour, I guess.



-- 
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com

Thomas Steinmaurer wrote:

> Care to keep IBX compatible with Firebird?

IBX is a CodeGear product. How does supporting Firebird benefit CodeGear? The answer is that there is no benefit that justifies the effort. CodeGear needs to invest its resources in other areas.

--
Bill Todd (TeamB)

Thomas Steinmaurer wrote:

> BDS is bundled with MSSQL

<TeamB hat off>

How many users do SQL Server, Oracle, DB2 and MySQL each have? How many users does Firebird have? How many complaints has Borland received in the past about problems with their drivers for the big players in the database world and about lack of timely updates to the drivers? CodeGear needs to fix the complaints they have received about support for the dirvers for the most popular databases before they even think about adding support for any others. If CodeGear could produce a set of drivers for SQL Server, Oracle, DB2 and MySQL that are so good they would put the third-party driver vendors out of business, and if the price of doing so is that CodeGear could not provide drivers for any other database, it would be the the best deal they have ever made in my personal opinion. In terms of relative benefit to CodeGear providing drivers for Firebird ranks with providing drivers for Pervasive and PostgreSQL.

CodeGear has a new team working on their database connectivity architecture but the significant thing is the quality of the engineers on the new team. These are very senior engineers with a lot of very impressive database experience. For that reason I am very optimistic that CodeGear's database connectivity support will improve dramatically. If that happens, the day may come when it makes economic sense to provide drivers for some of the less commonly used databases but it does not make sense now, at least not to me.

</TeamB hat off>

I agree. Let's not start a debate.<g>

--
Bill Todd (TeamB)

Bill,

> Thomas Steinmaurer wrote:
> 
> 
>>Care to keep IBX compatible with Firebird? 
> 
> 
> IBX is a CodeGear product. How does supporting Firebird benefit CodeGear? The answer is that there is no benefit that justifies the effort. CodeGear needs to invest its resources in other areas.

Don't get me wrong, I don't really understand this position. I still 
think that a tidy support for Firebird in CodeGears IDE product line 
*will* benefit CodeGears IDE, especially the BDS/Delphi business.

BDS is bundled with MSSQL, for instance. Borland (when the CodeGear 
announcement hasn't been published at that time) sponsored the this year 
Firebird conference, for instance. So, IMHO, re-thinking the usual 
position, especially from TeamB members, might make sense.

I don't want to start another "lets get ready to rumble" discussion. For 
those who have been at the Firebird conference, have seen, that there 
*might* be a movement.



-- 
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com

Thomas Steinmaurer wrote:
>>> The Classic architecture handles SMP just fine. 
>>
>> Not according to Jim Starkey, the original architect of InterBase -
>>
>> "I understand you you're saying, particularly since I designed it that 
>> way.  But classic doesn't scale well for update intensive 
>> applications, doesn't meet contemporary standards for robustness, and 
>> has unenforceable security.  If you are looking for an existence 
>> proof, yes, it does run on SMP, but not in a manner  attractive to new 
>> users."
> 
> You guys are reading the Firebird lists? Excellent! ;-)

I don't (actually I never have read a single message on any of the FB forums, 
but that doesn't stop people from sending me things they think are interesting), 
someone forwarded that to me.

> 
> Care to keep IBX compatible with Firebird? You would do a "few" Delphi 
> users with IBX legacy apps a favour, I guess.

All Firebird had to do was stay backwards compatible with IB 6.0, they didn't. 
I have explained in the past why I don't have time to work on both IBX and an 
FBX.  Nothing has changed on that front, nor will it.

-- 
Jeff Overcash (TeamB)
       (Please do not email me directly unless  asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly.  Specialization is for 
insects.   (RAH)

Sorry, I did not mean to start a debate.  Our application is very small. 
  We have retail book stores that will most likely never need more than 
6 computers used as point-of-sale units.  Connecting between stores is 
done over DSL for small, single-customer inquiries on a very limited 
basis.  Scalability beyond this level is not significantly likely for 
these bookstore applications.

Each computer is a single user from our standpoint, but may be as many 
as three concurrently running programs, each with multiple databases and 
multiple streams to the same table(s) open to the server.  If we count 
only the open databases (we use Delphi), each user would have only about 
  6 connections open at any point in time.  If we counted tables & 
queries, each user could have from 60 to 80 open at any given point.

Coming from a Paradox background, we did not expand much in our 
capabilities when we went to IB, as straight a conversion as we could 
do.  That is why we used IBO.  We just needed a simple minded database 
system.  IB was really overkill, but it came with Delphi and then 
Borland made the open source version available.

Using the newer dual-core, hyper-threaded processor boards appears 
inevitable since we just buy computers off the shelf and we have been 
getting some of these when we purchase systems in the $400 range.  If 
these are the same as SMP systems, then that needs to guide our 
direction also. This is only reason we are even looking at changing from 
IB 6.0.2.0 at this point.

With three stores (more in the future), if it is only about $700 per 
store for IB, that is not a big deal unless we have to keep upgrading 
and paying again.

Jack Mason wrote:

> Using the newer dual-core, hyper-threaded processor boards appears
> inevitable since we just buy computers off the shelf and we have been
> getting some of these when we purchase systems in the $400 range.  If
> these are the same as SMP systems, then that needs to guide our
> direction also.

	Dual core and SMP are different from an IB licensing point of view.
The dual-core license is cheaper than a server license + an additional
point of view (i.e., what you would need to use two processors on a
non-dual-core, SMP system).

	Also, consider that you don't have to license both processors unless
your app will be processor-bound. If the work you get the IB server to
do is disk-I/O bound or if only one user ever taxes the server at a
time, then there's no point in licensing both processors. If, on the
other hand, it's CPU-bound and multiple users are hitting the server
pretty hard at the same time, then a second CPU license is probably the
cheapest speed improvement available.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Useful articles about InterBase development:
  http://blogs.teamb.com/craigstuntz/category/21.aspx

	Shared caches are simply not possible with Classic. Saying that there
are a few cases where you might not want to use one doesn't change this
fact. And let's not pretend that they aren't better in general
applications; that implication is beneath comment. Whereas with
SuperServer the IB team could rather easily make the cache
per-connection instead of per-DB if customers were screaming for it. I
don't seem to see any QC requests for this, though.

	The security issues you don't seem to remember are explained
(accurately, if a bit indirectly) on your own web site:

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=art_fb_security

	The important bit is this: "in some cases running under the unix
uid/gid of the requesting client process." The issue is not with the DB
server internally (I agree there's no special security concerns inside
the server process) but rather with the inability to lock down file
access security at the OS level and restrict access to the server
machine.

	Which IB 7/2007 feature should Borland have dropped in order to spend
time nursing Classic along? None of them, in my book.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Want to help make Delphi and InterBase better?  Use QC!
  http://qc.borland.com -- Vote for important issues

Craig Stuntz [TeamB] wrote:
> 
> 	Along with all of the limitations classic has always had -- no shared
> cache, dicey security, etc. Borland stopped developing classic for a
> reason, and it looks to me like Firebird is going the same path for the
> most part.

1) In fact, no shared cache can give you way better performance in 
certain setups with large number of concurrent users. There are some 
hard numbers to prove that.

2) Dicey security? You should be prepared to support that claim with 
some evidence. Classic is AFAIK secure as Super Server.

3) While Borland stopped to develop Classic for a reason, Firebird 
project had a reason to develop it too, and even bring it to the Windows 
platform. Classic has certain characteristics that make it more suitable 
than SS for certain tasks. Borland lost several big users/customers 
thanks to their discontinuation of Classic.

4) Even with new Vulcan/Firebird 3.0 architecture, Firebird will not 
discontinue to support "classic". In fact, new architecture is a hybrid 
one, that allows to run FB in embedded, Super Server, Classic or "both" 
mode (multiple cooperating multithreaded servers).

best regards
Pavel Cisar
IBPhoenix

"Bill Todd" <no@no.com> wrote:



> How many users do SQL Server, Oracle, DB2 and MySQL each have? 


Loads. Not the point though. I think Loren Szendre put it best when he
said that IB was good enough for ~ 90% of apps - if you want higher
levels of whatever, go for Oracle (sorry if I've misquoted).


> In terms of relative benefit to CodeGear providing drivers for Firebird 
> ranks with providing drivers for Pervasive and PostgreSQL.



IMHO, the reason why Delphi has failed to make it to the big time is
because of the BDE. Borland should have supported native component
sets for Oracle, DB2, MSSQL, Sybase, Informix and Interbase (and
possibly Ingres and SAP) from the get go.



Paul...


-- 

plinehan __at__ yahoo __dot__ __com__

XP Pro, SP 2, 

Oracle, 9.2.0.1.0 (Enterprise Ed.)
Interbase 6.0.1.0;

When asking database related questions, please give other posters 
some clues, like operating system, version of db being used and DDL.
The exact text and/or number of error messages is useful (!= "it didn't work!").
Thanks.
 
Furthermore, as a courtesy to those who spend 
time analysing and attempting to help, please 
do not top post.

Paul <paul@see.my.sig.com> wrote:



> IMHO, the reason why Delphi has failed to make it to the big time is


Don't ya just love 20/20 hindsight. Anybody agree BTW?



Paul...


> Paul...

-- 

plinehan __at__ yahoo __dot__ __com__

XP Pro, SP 2, 

Oracle, 9.2.0.1.0 (Enterprise Ed.)
Interbase 6.0.1.0;

When asking database related questions, please give other posters 
some clues, like operating system, version of db being used and DDL.
The exact text and/or number of error messages is useful (!= "it didn't work!").
Thanks.
 
Furthermore, as a courtesy to those who spend 
time analysing and attempting to help, please 
do not top post.

Paul wrote:

> 
> 
> 
> "Bill Todd" <no@no.com> wrote:
> 
> 
> 
> > How many users do SQL Server, Oracle, DB2 and MySQL each have? 
> 
> 
> Loads. Not the point though. I think Loren Szendre put it best when he
> said that IB was good enough for ~ 90% of apps - if you want higher
> levels of whatever, go for Oracle (sorry if I've misquoted).

I am completely lost here. The subject of InterBase vs. other databases
was never mentioned. The question was whether CodeGear would or should
make the IBX components compatible with Firebird or provide a Firebird
driver for dbExpress. My  point was that there are many many many more
Delphi developers working with Oracle, DB2, SQL Server and MySQL than
there are Delphi developers who are working with Firebird. Therefore,
it is much more important to satisify the much larger group of
developers than it is to satisfy the small group using Firebird. If
they get to the point where they can satisfy both then great but if
they have to make a choice then they should satisfy the group of
developers that generates the most revenue.

> 
> 
> > In terms of relative benefit to CodeGear providing drivers for
> > Firebird ranks with providing drivers for Pervasive and PostgreSQL.
> 
> 
> 
> IMHO, the reason why Delphi has failed to make it to the big time is
> because of the BDE. Borland should have supported native component

I strongly disagree but I am not going to spend time debating the
point. There are two philosophies you can follow for database
connectivity. One is to provide separate components for each database.
The second is to provide an architecture that  makes it easy to change
the database you are connecting to without having to change your app.
In defense of Borland taking the latter approach I will only point out
that Microsoft started out with the first approach in ADO.NET 1.0 and
1.1 and immediately abandoned that approach for the second philosophy
in ADO.NET
2.0 due to vociferous complaints from their large customers.
 
> sets for Oracle, DB2, MSSQL, Sybase, Informix and Interbase (and
> possibly Ingres and SAP) from the get go.

Not even Microsoft, which has essentially infinite resources, provides
drivers for Sybase, Informix, InterBase, Ingres, SAP, Firebird,
PostgreSQL and MySQL.

-- 
Bill Todd (TeamB)

We won't have any processor bound applications that we know of.  We 
currently can't get IB to run well as a server on a dual-core system 
anyway.  The last time I saw the term SMP, about 12 years ago, it was 
used for symmetric multiprocessor.  Is this still what it references?

If so, I am missing the distinction between dual core and SMP since it 
used to be that dual core was just a special case of multiple processors 
accessing the same memory.  We have had SMP around since the early 
1960's, the only difference being today we can cram multiple processors 
on a single chip as opposed to on a single board or in a single backplane.

The systems we have will all be single user, with the processors 
(hopefully not the operating system) determining how many processors 
need to be invoked and when.  So, hopefully, we would only have to 
license each system.  However, we don't want to have to relicense them 
each year as upgrades come out.

What I don't understand is how Intel/AMD can build a PC board that has 
more processors, but runs an application 20 to 30 times slower than a 
single processor board.  Multiprocessors used to have a counter that 
detected instruction aborts and if a threshold was exceeded, that thread 
quit being multiprocessed.  Oh, well... Microsoft has never written a 
decent scheduler for Windows products, why should Intel have to learn 
how to correctly build processors....

Thanks for your reponses.

Jack Mason wrote:

> If so, I am missing the distinction between dual core and SMP since
> it used to be that dual core was just a special case of multiple
> processors accessing the same memory.  We have had SMP around since

It still is. The difference in licensing cost is arbitrary.

> the early 1960's, the only difference being today we can cram
> multiple processors on a single chip as opposed to on a single board
> or in a single backplane.
> 
> The systems we have will all be single user, with the processors
> (hopefully not the operating system) determining how many processors
> need to be invoked and when.  So, hopefully, we would only have to

The processors cannot decide how many processors to use because the
processors have no knowlege of instruction order and the instructions
within a thread must be executed sequentially.

> license each system.  However, we don't want to have to relicense
> them each year as upgrades come out.

Database servers typically ship a new major version every three years
and you only need to relicense on a major version change.

> 
> What I don't understand is how Intel/AMD can build a PC board that
> has more processors, but runs an application 20 to 30 times slower
> than a single processor board.  Multiprocessors used to have a
> counter that detected instruction aborts and if a threshold was
> exceeded, that thread quit being multiprocessed.  Oh, well...
> Microsoft has never written a decent scheduler for Windows products,
> why should Intel have to learn how to correctly build processors....



-- 
Bill Todd (TeamB)

Jack Mason wrote:

> The last time I saw the term SMP, about 12 years ago, it was
> used for symmetric multiprocessor.  Is this still what it references?

	Yes.
 
> If so, I am missing the distinction between dual core and SMP since
> it used to be that dual core was just a special case of multiple
> processors accessing the same memory.  

	Dual core means two physical CPUs on the same die/casing. In both dual
core and non-dual core (separate cases for the individual CPUs)
applications the processors use the same memory.

> What I don't understand is how Intel/AMD can build a PC board that
> has more processors, but runs an application 20 to 30 times slower
> than a single processor board.  

	It varies with applications, of course, but it is not my experience
that this happens. Some old software, such as InterBase 6.x, does run
more slowly on a SMP system, but you can work around this by affining
it to a single processor and then there's no big penalty. I have seen
cases of cache poisining by low-priority processes on hyper-threaded
systems. But for the most part I find that SMP gives a big speed boost,
especially with concurrent or multi-threaded processes.

	In particular, people who have more than one heavy user doing a
CPU-intensive task concurrently in IB 7+ will almost certainly see an
advangage from SMP.

> Oh, well...
> Microsoft has never written a decent scheduler for Windows products,
> why should Intel have to learn how to correctly build processors....

	I beg to differ. The scheduler in Windows 2003 was significantly
improved from its predecessors and actually works pretty well.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt 
  your DBs!  Open Edition users, get 6.0.1.6 from http://mers.com

> 	I beg to differ. The scheduler in Windows 2003 was significantly
> improved from its predecessors and actually works pretty well.
> 
Sorry, I never had occasion to use Windows 2003.  I'm glad they finally 
made it.

Pavel Cisar wrote:

> Craig Stuntz [TeamB] wrote:
> > 	Shared caches are simply not possible with Classic. 
> 
> That simply wrong statement. 

	I didn't say "not possible /to do well/" because I thought that was
obvious. Guess not. Shared memory between processes never ends well in
the real world.

> This article is dated way back to 2001. A lot changed in Firebird
> security front since that. You have to have group access with classic
> in local settings (which means true embedded mode), but that
> requirement is natural for any such system. 

	For in-process servers of course you'd need group access. But for
out-of-process, local connections it's still a security hole, and a bad
one at that.

	With that said, however, I'm beginning to think that Windows Vista
will kill local access via memory mapped files.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt 
  your DBs!  Open Edition users, get 6.0.1.6 from http://mers.com

Craig Stuntz [TeamB] wrote:
> 	Shared caches are simply not possible with Classic. 

That simply wrong statement. Tell that to PostgreSQL folks. Ever heard 
about shared memory between processes ? It's not done in Firebird yet, 
but it doesn't mean it couldn't be done. Look up some old threads about 
the topic in Firebird-Architect.

 > Saying that there
> are a few cases where you might not want to use one doesn't change this
> fact. 

This shared/no shared cache issue goes down to cache at file system. In 
fact, you always have shared cache at file system nowadays. Operations 
at file system cache can collide with large shared cache use pattern in 
a way that will significantly reduce the overall performance, and on the 
other side small not shared cache can give you performance boost.

 > And let's not pretend that they aren't better in general
> applications; that implication is beneath comment. Whereas with
> SuperServer the IB team could rather easily make the cache
> per-connection instead of per-DB if customers were screaming for it. I
> don't seem to see any QC requests for this, though.

Yes, that's done as an option in Vulcan/Firebird 3.0.

> 	The security issues you don't seem to remember are explained
> (accurately, if a bit indirectly) on your own web site:
> 
> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=art_fb_security

This article is dated way back to 2001. A lot changed in Firebird 
security front since that. You have to have group access with classic in 
local settings (which means true embedded mode), but that requirement is 
natural for any such system. With access over TCP/IP, Classic is as 
secure as Super Server, if not more.

best regards
Pavel Cisar
IBPhoenix

Loren Szendre <zorenlendry@yahoo.com> wrote:

<snip>
:>
:> But it still can't handle SMP and doesn't have EUA, 
:>Loren
Loren, what is SMP?

Regards,

-- Rod

Please note that, due to time differences etc, it might be 24hrs before I
get back to this group so please consider yourselves thanked for any help
you may be able to provide.

Rod wrote:

> Loren, what is SMP?

Symmetric MultiProcessors

-- 
Bill Todd (TeamB)

"Bill Todd" <no@no.com> wrote:

:>Rod wrote:
:>
:>> Loren, what is SMP?
:>
:>Symmetric MultiProcessors

Thanks Bill.


-- Rod

Please note that, due to time differences etc, it might be 24hrs before I
get back to this group so please consider yourselves thanked for any help
you may be able to provide.