Which FreeWare/OpenSource Interbase is the best?
PeaShooter_OMO
I am looking for a FreeWare/OpenSource Interbase that is stable and fast.
Which one is the best.
Thank you
Yannis
news:456a...@newsgroups.borland.com:
there is not an open source interbase that is mantained
any more. It has been forked to Firebird and the commercial
interbase.
Regards
Yannis.
Craig Stuntz [TeamB]
> 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
Loren Szendre
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
Jack Mason
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.
Loren Szendre
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
WillR
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
Craig Stuntz [TeamB]
> 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
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
Loren Szendre
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
Thomas Steinmaurer
> 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
Craig Stuntz [TeamB]
> 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
Bill Todd
> 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)
Aage Johansen
If Mr. Mason has a "three computer system", I wouldn't think a scaling
problem will hit him in the near future.
--
Aage J.
Bill Todd
--
Bill Todd (TeamB)
Jeff Overcash (TeamB)
>
> 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)
Thomas Steinmaurer
>
> 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.
Bill Todd
> 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
> 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.
Bill Todd
> 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)
Jeff Overcash (TeamB)
>>> 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.
Jack Mason
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.
Craig Stuntz [TeamB]
> 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
Pavel Cisar
>
> 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
Craig Stuntz [TeamB]
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
Paul
Paul <pa...@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
"Bill Todd" <n...@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.
Bill Todd
>
>
>
> "Bill Todd" <n...@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)
Jack Mason
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.
Bill Todd
> 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)
Craig Stuntz [TeamB]
> 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
Jack Mason
> I beg to differ. The scheduler in Windows 2003 was significantly
> improved from its predecessors and actually works pretty well.
>
made it.
Pavel Cisar
> 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.
Craig Stuntz [TeamB]
> 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
Rod
<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.
Bill Todd
> Loren, what is SMP?
Symmetric MultiProcessors
--
Bill Todd (TeamB)
Rod
:>Rod wrote:
:>
:>> Loren, what is SMP?
:>
:>Symmetric MultiProcessors
Thanks Bill.