Hello,

I'm going to ask the same question as I previously asked in berkeley-db
newsgroup:

I'm coming from an MS-database world, using Access with VB, and SQL
Server with C#. I'd like to try an opensource database instead of SQL
Server one, but couldn't find answers to some basic questions:
- can PostgreSQL database be stored in a single file, such as Access'
mdb ones ?
- if the answer is negative, in computers which use a program using
PostgreSQL, how is stored the database and is it easily moveable ?
- is there a DbProvider in ADO.Net 2 which works fine with PostgreSQL
? Or a separate one ? I'd like to use the database with C# and benefit
of DB fonctionality of it.

Thanks in advance for any answer.

Vivien Parlat <pocky6 (AT) gmail (DOT) com> wrote:
It is obvious that you come from an MS-database world.

No, you cannot have a PostgreSQL database in a single file.

A database is NOT something you carry around in a large file together
with appication code.

A PostgreSQL database is something running on a database server machine,
it is a process to which you can connect with so-called clients to
communicate with it. On the machine that runs the application (which
can, but need not be the same as the machine runing the database)
you install a client and with it access (the verb, not the Microsoft
product) the database from your application.

I don't know what is in ADO.Net 2, but there is a .Net-Provider for
PostgreSQL called Npgsql.
You can also access PostgreSQL via ODBC if you install the ODBC driver on
the client machine.

Yours,
Laurenz Albe

In article <1161013966.104089 (AT) proxy (DOT) dienste.wien.at>, Laurenz Albe wrote:
Be nice.


Oh yeah? What if I do a pg_dump of a database,
directing its output into a file. Then I make a
tarfile of that file and the directory on
my web server where the database application
program runs. Say it's Wordpress or something.
Now I have a single file with the whole database
on it. I can gzip it and put it on my USB drive
and wear it around my neck. Very stylish.
Can't *run* it like that, but OP is interested in
backups and switching hosting providers, right?



I once wrote a little database app during a plane ride.
To do it, I installed Apache, PostgreSQL, some Perl modules,
and a lightweight web browser on my laptop. I use multiple
partitions, but a lot of people install linux all on one
partition these days, with a swap file. Had my setup
been all in one partition, I would have had the application,
the database engine, the middleware, the client, the logs,
and the kernel, all in one file (/dev/hda1), running.

Don't say "can't." Say "I don't know how yet."


Cameron

Begin <slrnej7vc5.esc.spambait (AT) truffula (DOT) sj.ca.us>
On 2006-10-16, Cameron L. Spitzer <spambait (AT) merde (DOT) greens.org> wrote:
It's true, there's no overt cusswords, and the reaction is excusable on
grounds of fucked up question. What are you complaining about? ;-)


Then you'd have a dump of the database in a single file. Not a running
database. I had also initially assumed the question was about that.


Something for the OP (Vivien Parlat, that's you) to answer, and learn to
state right away next time.


[database app on a plane]
By virtue of that file being a block device. While a lot of things on
unix do look like a file, that doesn't mean they really are a file.

Now we could argue about what really constitutes a file and what does
not, but I'll just say that stretching it like that is fine for the sake
of argument, but not terribly useful.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

Cameron L. Spitzer <spambait (AT) merde (DOT) greens.org> wrote:
I didn't intend to be abusive, my apologies if it sounds that way.
I don't think that 'coming from an MS-database world' is bad or
ridiculous per se. In fact, it's the right direction to move.

I'll continue to be nice, and won't accuse you of nitpicking :^)
The original poster was certainly talking about an operational
database that you can connect to.

I guess that you have as little exposure to Microsoft Access
as I have, so you probably are not aware that with this piece of
software you can create one big file that contains a 'database' and
application code, and by double clicking on the file you can start the
application and access the data contained in the database.

If this file is fairly large and several people access it via network
concurrently, it's a good way to bring a strong network to its knees.

Ok, sorry, but now you're really nitpicking.
Most things on a UNIX type operating system can be called a file with
some justice, but unless you're out to confuse somebody who is coming
from a Microsoft environment, it's not wise to stress this terminology.

Can't. :^)

Yours,
Laurenz Albe

In article <1161069199.184159 (AT) proxy (DOT) dienste.wien.at>, Laurenz Albe wrote:

Especially if you've been using Access... I'd touch it only if
threatened with a rifle... (yes, I've once tried to build an
application on top of it, aaaarghhhh...)

BTW, there is something called SQLite, which is a single file, if that's
what really is needed. Haven't ever tested but might work as a replacement
for Access.

Calling Access a database is an insult to all decent databases. It's an
overgrown cardfile with some relational add-ons and horribly
non-standard SQL-interface...

--

Freedom of speech, basic right, not a privilege!
Laura Kataja
kisuli miau iki poäng fi
Kuvaelma: <http://www.helsinki.fi/~likataja/Kirjakauppa.html>

Laurenz Albe wrote:
In fact I use Oracle too, so the idea of an client/server database
isn't new to me. My goal is to find an alternative to MS-databases,
which has the same property of being stored into a limited number of
files, without installing anything more in users' machine. The db
purpose is to store personal info only, so a client/server architecture
seems too heavy to me.

I wasn't hurt. I yet saw that database-in-one-file seems to be more
present in MS world. But asking the same question in Berkeley Db
newsgroup learnt me that open source database could do this too
(however, no direct ado.Net link seems to exist)

I confirm that.

Because the file my soft will store is only intented to store personal
data, (but big ones, and with search features), I won't break any
network.

I know the "in unix everything is a file" (thanks to university), I use
Access because my job needs me to do it. What I'm doing (as a personal
project) is a small app, I don't consider asking (potential) user to
install an Oracle server at home.
Visual C# offering smart and useful database integration, I'm looking
for a database which would offer an Ado.Net 2 compliant interface, as
well as easy storage.

I said the same thing about VB, and I have to use it at work too (my
"rifle" is a payroll).
I don't think a technology is fully good nor bad (even Win Millenium,
which could probably be better described by "a joke"), VB is full of
good ideas, badly implemented but original. How many years between VB's
"For each" and java's new (bad) syntax for "for each" ?
The same way, I see Access as an attempt to bring database prog... no,
manipulation, to the masses. Years after that, MS gives C# which is a
much more cleaner implementation of concepts the developer is now used
to see and use.

I think I'm going to try it (depending on its features), it seems to
have ado.net db providers.

Maybe it is a database-for-kids. But as weak as it is, serious projects
are built over it, as well as VB (old projects, yes...); do you think
the same thing of SQL Server ?

Thanks for all which answered to my questions. I read interesting
thoughts.

On 2006-10-17, Vivien Parlat <pocky6 (AT) gmail (DOT) com> wrote:

Then you could try SQLite and these:
http://sqlite.phxsoftware.com/
http://sourceforge.net/projects/adodotnetsqlite

--
regards,
wojtek

Vivien Parlat <pocky6 (AT) gmail (DOT) com> wrote:
Since I didn't know that, I tried to phrase my reply so that it does not
rely on that knowledge.

Yours,
Laurenz Albe