Skip site navigation (1) Skip section navigation (2)

Re: Source name not found

From: Frank Seesink <frank(at)mail(dot)wvnet(dot)edu>
To: pgsql-cygwin(at)postgresql(dot)org
Subject: Re: Source name not found
Date: 2004-06-16 01:20:00
Message-ID: cao78r$ikb$1@sea.gmane.org (view raw or flat)
Thread:
Lists: pgsql-cygwin
Barry,

Sorry to hear that the experience has left you disinterested.  DataBase 
Management Systems (DBMS) are, by their very nature, a bit of a 
challenge, though.  When it comes to any decent DBMS, there's all the 
system admin challenges (install / config / running / making DBMS work 
on a network / etc.).  Then there's the DBA challenges (managing the 
datastores themselves, creating databases where users do their storage / 
queries / etc.).  Then there's the user/developer end (learning SQL, 
doing the 'work' as it were, etc.).  When you're wearing all the hats, 
it can be a bit much.  I know.  I have a LOT of hats. :-)

Of course, just to be clear on a few things, you appear to have made 
things more complicated than possibly necessary.  Might I offer some advice?

DBMS can be fantastic storage facilities for data (the name kinda 
implies it, right?).  But their relative complexity usually scales with 
their performance ability.  That is, for simple db tasks, apps like MS 
Access can be great, since they store the entire database 
(tables/forms/reports/etc.) all in a single file.  And MS Access is 
'easy' to use with its GUI and commonality to other Office apps.

But MS Access starts to suffer as you throw more data / interaction at 
it.  So then you might look at more 'serious' systems...MySQL (very fast 
in solutions doing most reads/queries)... PostgreSQL (far more ANSI SQL 
compliant and kind of a poor man's Oracle)... MS SQL Server....  But 
you'll note that the amount of skill/time needed for these also grows.

Finally, if you're a really serious user (financial markets, whatnot), 
either a commercially supported version of MySQL/PostgreSQL/<other open 
source DBMS> with possible additional features like replication, 
built-in backup/recovery solutions/etc., or you go get a serious, 
commercial, proprietary DBMS like Oracle, IBM's DB2, etc.  At this point 
you may be looking at consulting time, hiring people to handle the 
individual tasks mentioned earlier, and so on.  More skill/time/money again.

When I look at using a database as a solution to a problem, I basically 
walk the following list to see where I need to be:

1.  flat text file
	* good for simplest tasks
2.  SQLite (www.sqlite.org)
	* embedded DBMS; small, fast, multi-platform library
	* works with many languages (including Perl; see site)
	* stores all data in single file which is binary compatible
	  across OSes
	* limited to situations where you embed DBMS into your app
	  (i.e., not for client/server, high-volume connections, or
	  setups where DBMS runs on one box, your app on another)
3.  MS Access or similar
	* fine for office db needs where user needs quick/dirty
	  simple solution
4.  MySQL
	* far better performance than MS Acces
	* various GUI frontends exist
	* free for toying but with option for paid support/etc.
	* has db replication capability built-in
	* very popular with lots of code/support/whatnot available
	* excellent in environs where you mostly do reads/queries
5.  PostgreSQL
	* excellent ANSI SQL support; great for learning/using SQL
	  commands at every level (basic queries, creating tables/etc.,
	  and doing dba work)
	* again, free for toying and even high-end use, with options
	  for commercial support if needed.
	* again, various GUI frontends exist
	* not as popular as MySQL, but depending on tasks, better suited
	* easier to port other DBs to like Oracle, due to its strong
	  SQL support
6.  Oracle/IBM DB2/etc.
	* when you can't afford any downtime, want someone else's butt
	  to chew out when there are issues, and you have deep deep
	  pockets...

To be perfectly honest, I'm not a fan of MS SQL Server, but if I had it 
in the list, it would be at the same level as MySQL or PostgreSQL.  (I 
just can't personally see a need for an expensive, proprietary solution 
when a free, open-source better one exists, but that's me).

Now in your case, it sounded like you're tackling quite a few things, 
which may in part be why you feel so overwhelmed.  Perl, Perl DB 
modules, Windows, Cygwin, PostgreSQL, ODBC, SQL... that's a good bit of 
stuff to get through when you "don't expect the code to do anything 
useful." :-)

One step:  skip ODBC and use a Perl DB module which talks directly to 
PostgreSQL.  That's one possibility.

More than likely, however, you might want to look into something like 
SQLite instead, at least for starters.  At least 2 wrappers exist for Perl:

	http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers

With this, all you do is write your Perl scripts using the same kind of 
Perl DBI.  The difference is that there's no DBMS administration, no 
installation, no nothing.  SQLite generates a single, binary file to 
store all the tables, data, etc.  It's about the easiest way to use a 
SQL engine there is.

Once you're comfortable with the DBI coding and SQL itself, if you 
should write an app that scales or requires the DBMS to be on a 
different PC than the Perl script, at this point try to come back to 
PostgreSQL.  Yes it requires more work.  I doubt anyone would deny that. 
  And though right now it may not seem that way, I don't know anyone 
who's more committed to helping folks run PostgreSQL under Cygwin than 
Jason Tishler.  Not only does he write up the READMEs, but he's the one 
who compiles the binaries which you can install by simply using Cygwin's 
setup.exe.  And those READMEs, though may appear overwhelming now, will 
make more sense as your experience grows.

I've been where you seem to be at right now (at least in your 
frustration with PostgreSQL).  But please don't let it deter you.  I had 
years of DBMS background before coming at PostgreSQL, and though the 
initial install/setup was no point/click affair, once you've seen what 
it can do and are familiar with the various systems out there, 
PostgreSQL's actually quite a robust piece of software.

It's just that right now it appears you're trying to kill a fly with an 
elephant gun.  Anyway, just some food for thought.  Best of luck 
whatever you choose to do.

P.S.	Apologies on not explaining clearly about DNS/IP addresses, etc.
	Yet one more piece of the puzzle: networking.  In Windows, at
	the Command Prompt type the command
		ipconfig
	and it should tell you what your PC's IP address is.  Networking
	is what I do for a living, so I got a little flippant.  But to
	keep it simple, if you want to run a database that you can
	access from a network, there must be some 'address' that you can
	reach the database at, does that make sense?  Kinda like knowing
	my phone number if you want to call me.

	The most common network system in the world is the Internet,
	which relies on a networking protocol known as TCP/IP.  Though
	explaining networking is well beyond an email like this, just
	note that every computer on a network must have a unique address
	or things just get ugly.  Imagine if we only had first names.
	How would we communicate with each other?  "Hey Frank?"  Now
	who would answer?

	Depending on your network setup, you may be using
	something like DHCP which 'dynamically' provides your PC with
	an address.  This is like getting a different phone number each
	day you wake up.  Sure you can call others, but how are they
	supposed to reach you?  This is only a problem if your job is
	to be someone others must reach (i.e., a database system which
	your app needs to talk to).  So if you decide to run something
	like a database (or webserver, etc.), it is imperative that you
	have some set (static) way of identifying the address of the
	server so that your program can reach it.  Does that make sense?

	Next is security, where in the case of PostgreSQL, you can
	specify in pg_hba.conf the addresses (or phone numbers) from
	which you will accept connections (or calls).  It's like
	CallerID for computers. :-)

	Anyway, this is already too long a message.  Sorry about that.
	But just note that if you want to run a database server on a
	network, yes, you'll also have to add some basic networking
	knowledge to your toolbelt.  Welcome to the information age, eh?


- Barry - wrote:
> Thanks for all the details. A previous reply to my post led me to the driver
> and where to do the Windows configuring, and I was just about to continue
> the database setup, but now it seems even more complicated. I have a single,
> home PC, and I wanted the database to run from this one computer. Possibly,
> in the future, a second home computer would write to the database. I don't
> know where to find the DNS/IP of the "server" or whether there is one, I'm
> not at all familiar with configuring PostgreSQL, and I'm generally uncertain
> about much of what I've quoted below. I've lost interest (and lots of time)
> in this.
> 
> I thought I'd be able to find a simple alternative to saving data in regular
> files. I could have easily created a storage solution that meets my needs
> with Perl, even without getting fancy with a function like seek, and another
> option was Perl's DBM::Deep module, but I figured a regular database would
> make accessing the data faster and easier once I learned SQL or one of its
> flavors. It's debatable whether I should have bothered even if it were as
> simple as I thought. As it turns out, there was no installer, the
> instructions didn't work, the fixes I found elsewhere only got me to the
> command prompt interface, and it now sounds like that wouldn't have worked
> even if I didn't need access from Perl.
> 
> All this it too much. There's too big a learning curve from my old methods
> of flat file storage to this, and the only help I've found at this stage is
> through helpful people like you who are willing to take the time to explain
> some of the things involved, rather than through the instructions that I've
> been following or links from them to information I need to complete the
> installation.
> 
> Thanks for your help everyone, but no more databases for me.
> 
> Barry
> 
> 
>>The rest of the information is where you describe the
>>backend DBMS setup.
>>
>>Data Source: <DSN>                            (e.g., MyApp)
>>Database:    <name of PostgreSQL database>    (e.g., MyAppDB)
>>Server:      <DNS/IP of PostgreSQL server>    (e.g., myserver.com)
>>Port:        <TCP port PostgreSQL listens to> (e.g., 5432)
> 
> 
>>1.  Note above that Port: is one of the options.  Though I can't say for
>>     certain, this to me indicates that PostgreSQL ODBC requires that you
>>     setup your PostgreSQL server to listen via TCP/IP (as opposed to
>>     using the Unix sockets approach).  This means you had better be
>>     familiar with configuring PostgreSQL, which typically involves
>>     making changes to a few config files, now typically located in
>>
>>         /var/postgresql/data
>>
>>     The files you want to familiarize yourself with are pg_hba.conf,
>>     where you set your security (what IP addresses/users can access
>>     PostgreSQL, etc.), and postgresql.conf, where you'll need to
>>     specify that PostgreSQL should use TCP/IP (tcpip_socket = true)
>>     and specify the port to listen on (5432 is the default).
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
> 


In response to

Responses

pgsql-cygwin by date

Next:From: K-SudhakaranDate: 2004-06-16 05:05:13
Subject: Re: hi needed help in postgres sql problem.
Previous:From: - Barry -Date: 2004-06-15 22:43:50
Subject: Re: Source name not found

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group