Thread: GTK or TCL/TK ... what do you prefer ? (beginner)
Hello, Forum
In my 1st message. I'm developping in MSVB 6.0 & Access.
I am beginner in Linux. I want to develop some easy program.
I'd like to program with a dev.lang. to Linux and to know your opinions to
interact with Posgres.
No programs made at the moment. Nothing.
I'm studing intensively all the docs.
Thanks in advance. I need a lot of Help.
(...little bit affraid)
Marcel Sierra i Alegret
from Barcelona
Restoring old database with OIDs that are now in use by another database after initdb = problems?
From
"Robert B. Easter"
Date:
I'm wondering what would happen if I were to backup/archive an old database with OIDs, then later someday, restore it after I've since done an initdb and there is someother database using the same OIDs as the old database. If I restore with OIDs, that would cause the OIDs to not be unique within the entire data directory. Would PostgreSQL have any problems with this? If PostgreSQL references all data by OID internally, then this would cause an OID to reference more than one object - a possible ambiquity? I'm trying to decide whether to use OIDs or sequences for unique ids. I want to use the method that will work most reliably. Trouble free backup and restore is very important. OIDs look good since they are always there so they are simple and there's little you can do to misconfigure them. Serials/sequences might be better if I need sequential numbers but I don't really - just unique is good enough. Again, I want to use what is simplest but more importantly, that stands the best chance of not being corrupted during backup/restore. Any caveats or experiences anyone can share would be great! Robert B. Easter reaster@comptechnews.com
Re: Restoring old database with OIDs that are now in use by another database after initdb = problems?
From
Bruce Momjian
Date:
>
> I'm wondering what would happen if I were to backup/archive an old
> database with OIDs, then later someday, restore it after I've since done an
> initdb and there is someother database using the same OIDs as the old database.
> If I restore with OIDs, that would cause the OIDs to not be unique within
> the entire data directory. Would PostgreSQL have any problems with this? If
> PostgreSQL references all data by OID internally, then this would cause an OID
> to reference more than one object - a possible ambiquity?
Having duplicates in different tables really is not a problem.
>
> I'm trying to decide whether to use OIDs or sequences for unique ids. I want
> to use the method that will work most reliably. Trouble free backup and
> restore is very important. OIDs look good since they are always there so they
> are simple and there's little you can do to misconfigure them.
> Serials/sequences might be better if I need sequential numbers but I don't
> really - just unique is good enough. Again, I want to use what is simplest
> but more importantly, that stands the best chance of not being corrupted
> during backup/restore.
>
My book has a chapter on this:
http://www.postgresql.org/docs/awbook.html
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Marcel Sierra wrote: > Hello, Forum > > In my 1st message. I'm developping in MSVB 6.0 & Access. Have you ever developed anything with VB and Access ? If your answer is yes, then you have already a basic understanding. If your answer is no, you should do that first. Is it imperative that you use these programs ? Is it a project that should be run using these programs, e.g. because it needs to be on a network with Wintel PC's ? > > > I am beginner in Linux. I want to develop some easy program. There is Linux, there is postgreSQL and there is a whole bunch of programs to do development with. First, take some time with the documentation that comes with every Linux distribution (in /usr/doc). > > > I'd like to program with a dev.lang. to Linux and to know your opinions to > interact with Posgres. > Do you want to write programs running on Linux, which can access postgreSQL, or do you want to write programs using VB and Access, which can access postgreSQL on a server ? In the first case, you have several possibilities. You could be programming in C or C++, but I do not recommend that. You could use an interpreted language, like Perl, Tcl or Python. These have all an interface with postgreSQL, and also the Tk toolkit, which makes it possible to create graphical applications. However, being busy like that means you are learning several things at once : - Linux - postgreSQL - one of these interpreted languages - Tk If you must connect from VB/Access to postgreSQL, you should install the ODBC interface. > > No programs made at the moment. Nothing. Do you mean under Linux, or in general. In the latter case, I suggest that you find a good book about programming. > > > I'm studing intensively all the docs. > > Thanks in advance. I need a lot of Help. Are you a student ? If so, I suggest that you look into the library of your school after books on programming, and books about databases, and that you start learning a classical programming language, and not jump directly in an environment like the above. > > > (...little bit affraid) > > Marcel Sierra i Alegret > from Barcelona Jurgen Defurne defurnj@glo.be
Dear Marcel,
I do not know Postgres very well. However, our team has built a number of
applications using TCL/TK. At present we are using Postgres for our local
database, because we are stuck with Unix until the department as a whole
can upgrade to Windows NT.
Unix don't have certain concepts like ODBC that we take for granted in a
Windows networking environment. Many Unix programmers simply use flat
files for local storage, because database access is so slow, and there is
the additional administrational overhead.... what a bother. For some this
is job security though, writing code that is tightly coupled to everybody
elses code, and nobody else can understand.
As a consequence, data access is coupled tightly to production
applications, making them expensive to build and difficult to maintain. We
survive by decoupling the data access from the applications completely...
by writing a bunch of TCL procedures with well-known names, and putting
them into an incrTCL class. I call it DataServices. It holds all of the
SQL, all of the calls into the Postgress library. The incrTCL class has a
constructor and destructor that connect to and disconnect from, a database.
The advantage of using TCL is that it is a very powerful processor of lists
and strings. A procedure, if it returns a list, or even better a keyed
list (containing the headers and the data, such as "person.name {Rob}",
"person.address {One Buckingham Place}", will simply return a list, an
emplty list if no data matches, or raise an exception which you can handle
with an error dialog, if the database is dead.
This way, when we find a database that gives us better performance and does
not require major hacking, we will only have to rewrite a single class, not
every application that we support.
It would be great to be able to access an Access database from Unix, across
a network. Maybe this Spring I'll have time for a project like this.
I prefer to concentrate on what I WHAT to build, instead of wasting a lot
of time worrying about how to do it! Hacking makes you lose sight of the
big picture. My advice is to stop worrying about documentation, start
experimenting, and decide for yourself, what you like to use. I highly
recommend the Scriptics distribution of TCL/TK called TCLPro, found at
http://www.scriptics.com.
Cheers
Rob
Robert Wagner wrote: > It would be great to be able to access an Access database from Unix, across > a network. Maybe this Spring I'll have time for a project like this. Check out unixODBC at www.unixodbc.org. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Mon, 1 May 2000, Robert Wagner wrote: > Unix don't have certain concepts like ODBC that we take for granted in a > Windows networking environment. Huh? there is a UnixODBC driver for PostgreSQL, that, I believe, Thomas Lockhart has used with Applixware, at the least ...
On Mon, 1 May 2000, Robert Wagner wrote:
> Unix don't have certain concepts like ODBC that we take for granted in a
> Windows networking environment. Many Unix programmers simply use flat
> files for local storage, because database access is so slow, and there is
> the additional administrational overhead.... what a bother. For some this
> is job security though, writing code that is tightly coupled to everybody
> elses code, and nobody else can understand.
Take a look at the Perl DBI module and then re-evaluate your above
statement. And while Perl not always be bets the choice for all
applications, Perl supports both GTK AND the Tk widgets. The user
interface is really a trivial point -- it's your backend where the most
important engineering takes place. I personally tend to code for a 'model
view controller' environment, and separate data access from data
presentation from the ground up.
The Unix environment tends to be server-centric, not client or end-user
interface centric like the Windows environment is. There *are* ODBC
drivers for all of the major Unix database systems, including Postgres and
MySQL, if you want to connect to Unix servers form, say, an Access
database or via Visual Basic.
> It would be great to be able to access an Access database from Unix, across
> a network. Maybe this Spring I'll have time for a project like this.
This is really begging the question, but why would you want to do that?
It would be easier to use Access to connect to the Unix-based database. I
have done lots of projects using Access to connect to the server database
(mostly Postgres!). I found that doing queries in Access through ODBC
was a horribly slow process, but using a pass-through query was blazingly
fast. Access was not intended to be used for a backend for anything but
very small projects. If you want something bigger, I'd use MS-SQL 7, or
PosgreSQL/MySQL/whatever off of a Unix-ish machine.
Brett W. McCoy
http://www.chapelperilous.net
---------------------------------------------------------------------------
egrep patterns are full regular expressions; it uses a fast deterministic
algorithm that sometimes needs exponential space.
-- unix manuals
On Mon, 1 May 2000, Brett W. McCoy wrote:
> On Mon, 1 May 2000, Robert Wagner wrote:
>
> > Unix don't have certain concepts like ODBC that we take for granted in a
> > Windows networking environment. Many Unix programmers simply use flat
> > files for local storage, because database access is so slow, and there is
> > the additional administrational overhead.... what a bother. For some this
> > is job security though, writing code that is tightly coupled to everybody
> > elses code, and nobody else can understand.
Oh, yeah, I forgot to mention there is a Unix ODBC library, found at
www.unixodbc.com
Brett W. McCoy
http://www.chapelperilous.net
---------------------------------------------------------------------------
egrep patterns are full regular expressions; it uses a fast deterministic
algorithm that sometimes needs exponential space.
-- unix manuals