Обсуждение: need good editor for postgreSQL
Anyone know where I can find a good editor for postgreSQL with runtime environment?
Hey, I'm new.
Hey, I'm new.
Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.
--- Mark Deering <reidardeering@yahoo.com> wrote: > Anyone know where I can find a good editor for postgreSQL with runtime environment? On linux, I like vim. On Windows, I like gvim. :-) Of course, the reason why is that I really like vim. ;) Well, it does a good job at syntax highlighting SQL, PLpgSQL. Regards, Richard Broersma Jr.
--- Mark Deering <reidardeering@yahoo.com> wrote: > > I have fair programming experience (VBA, Java, Python) but my end-users want GUIs and nothing > but. No TLAs ("Three Letter Acronyms"). If they can't use it right away, they don't believe in > it. I need to make any new database look good fast, or else I'm back to downloading their stuff > to my main every week. I fear no software but my colleagues are demanding, and I have no time. > I want to get something up and running that they can see and that looks like something they are > used to. I want to transition before they know anything has happened.. Thus, I work over-time > on my own time until I solve this problem. Needless to say they don't want to pay for anything. Well my first suggestion is to reply-all so that everyone on this mailing list that IS smarter than me can give you better answers. ;) Personally, I have an access database that I reciently migrated. I had many of the same concerns as you have. Initially, I had all of the forms, reports, and data in access. To start off with, I spent some time to document the DDL statements that I would need to recreate the DB schema and relationships in postgresql. First, I created all of the schema entities on the postgres server. Second I linked these table to the access front-end using ODBC. Third, I "appended"/inserted the data from access table to postgresql Linked tables. Fourth, I dropped the access tables and renamed to postgresql linked tables to the original table names. The reports and forms didn't seems to care since they continued to work as expected. However, there are some points to watch for. If you have alot of queries like: SELECT * from a_one_and_a_half_gigabite_table; Postgres will not be able to give you same data <over ethernet> through-put that a client side access table will give. Alternatively, if you are querying small sub-sets of data from a huge table, you will notice that PostgreSQL wins handsdown against MS-access when you are tranferring data over ethernet. Another great advantage to splitting the GUI front-end from the DB back-end is that while your users are making due with MS-access as a front end linked to postgresql, you can seperately being development on a better custom front-end. Perhaps you could use java for example to do this work. Once you are done, they can try it out what you have developed. If they like it, great. If they don't, they can continue to use the access front-end that they know and love. Here are some links that I've never used, but maybe they will be helpful to you: http://www.postgresql.org/docs/techdocs.3 check out the sub-heading for "Microsoft Access" Regards, Richard Broersma Jr.
--- Mark Deering <reidardeering@yahoo.com> wrote: > > I have fair programming experience (VBA, Java, Python) but my end-users want GUIs and nothing > but. No TLAs ("Three Letter Acronyms"). If they can't use it right away, they don't believe in > it. I need to make any new database look good fast, or else I'm back to downloading their stuff > to my main every week. I fear no software but my colleagues are demanding, and I have no time. > I want to get something up and running that they can see and that looks like something they are > used to. I want to transition before they know anything has happened.. Thus, I work over-time > on my own time until I solve this problem. Needless to say they don't want to pay for anything. Well my first suggestion is to reply-all so that everyone on this mailing list that IS smarter than me can give you better answers. ;) Personally, I have an access database that I reciently migrated. I had many of the same concerns as you have. Initially, I had all of the forms, reports, and data in access. To start off with, I spent some time to document the DDL statements that I would need to recreate the DB schema and relationships in postgresql. First, I created all of the schema entities on the postgres server. Second I linked these table to the access front-end using ODBC. Third, I "appended"/inserted the data from access table to postgresql Linked tables. Fourth, I dropped the access tables and renamed to postgresql linked tables to the original table names. The reports and forms didn't seems to care since they continued to work as expected. However, there are some points to watch for. If you have alot of queries like: SELECT * from a_one_and_a_half_gigabite_table; Postgres will not be able to give you same data <over ethernet> through-put that a client side access table will give. Alternatively, if you are querying small sub-sets of data from a huge table, you will notice that PostgreSQL wins handsdown against MS-access when you are tranferring data over ethernet. Another great advantage to splitting the GUI front-end from the DB back-end is that while your users are making due with MS-access as a front end linked to postgresql, you can seperately being development on a better custom front-end. Perhaps you could use java for example to do this work. Once you are done, they can try it out what you have developed. If they like it, great. If they don't, they can continue to use the access front-end that they know and love. Here are some links that I've never used, but maybe they will be helpful to you: http://www.postgresql.org/docs/techdocs.3 check out the sub-heading for "Microsoft Access" Regards, Richard Broersma Jr.