Re: Source name not found

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
>