[EMAIL PROTECTED] wrote: > About the errors you were speaking about in your install.txt file. > Is it possible to use C++ to call PostgreSql with the errors? I > couldn't. I got the errors you wrote about. Should I "ignore/continue" > or what should I do?
I checked install.txt and I saw multiple mentions of errors. Show us the build output and we can tell you if there is a problem or not. > 2. > I tried to read the README file to see where I should write my log in > information (username, password host etc.), and I copy pasted > the code (2rows) you had in your file, my question is, is this enough to > connect? I couldn't test since I got those memory errors. Those memory errors? Again, show us the output! About how to connect: you should instantiate a "connection" object with a connection string as a parameter. The format of connection strings is discussed in the README, in the section called "Connection strings". > I have tried for 3 weeks to get Postgres to work, I'm about to give up, > and test mysql instead. I'll be brutally honest with you. Even if you decide to go for mysql instead, you need to learn a valuable lesson first. When you ask people questions, you need to provide DETAILED and SPECIFIC information about what you're doing. Right now, you're generally saying things in a vague way, or you refer to things that are open to multiple interpretations. I'll give you three examples, all from this e-mail. Watch and learn. Example 1: When you say "The code (2rows) you had in your file", you neither mention which file you're talking about, nor which code you're talking about. Jeroen owns all of the files in the project, so "your file" can be any file at all. A clearer, more useful way of saying this would be "I copied the code from line 628 in the file test072.cxx." This makes sure that people don't have to guess what you're talking about. Example 2: When you say "the errors you were speaking about in your install.txt file", you're saying something that is open to multiple interpretations because the word "error" occurs six times in that file. None of the occurrences of the word "error" are *clearly* the errors that you're talking about, so nobody who reads this has a clue which errors you mean. Showing the build output is a concrete, clear way of showing what errors you mean. Example 3: Further down, you say "I couldn't test since I got those memory errors". But what memory errors are you referring to? They are not the errors you mentioned in example 2, right? There are thousands of things that could be described as "memory errors". Again, actual output and program results are a very useful tool to let people know what you mean. Of course, you don't have to listen to me. But if you don't give detailed, specific information, people in the open source communities will definitely not give you what you want. The libpqxx community is generally patient, and people are willing to invest extra time to get the information they need in order to help you. Other communities may not be so nice. In fact, I know quite a lot of communities where a mail like your very first mail to the libpqxx mailing list would have either gone ignored completely, or would have given you a whole bunch of irritated reactions immediately. Anyway, I have another unrelated suggestion. You are obviously not an experienced C++ programmer, so would it not be a good idea to access postgresql with a scripting language, such as python, perl or even Visual Basic (using the postgresql ODBC driver)? Cheers, Bart _______________________________________________ Libpqxx-general mailing list Libpqxx-general@gborg.postgresql.org http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
