Re: Retrieving info from a Joined column
From: Bruce Therrien [EMAIL PROTECTED] Date: 2003/11/28 Fri PM 01:42:14 CST To: [EMAIL PROTECTED] Subject: Retrieving info from a Joined column We ahve a column in our table that has new info added each time using a JOIN function. The data is separated using a : separator. This doesn't answer your question... However, note that in most instances using columns with multiple values is a bad idea in a relational database. If possible, you'd be better off with a design that does not require multiple values in a single column. How does one retrieve this info from the colomn and put it into list format, or check for duplicates, or do a search in the column for a certan string. We use PERL for all database entries and retrievals. Sample data 1223:1897:9807:36754:20875 Thanks, -- Bruce Therrien [EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Please analyze my project table design
From: Paul Fine [EMAIL PROTECTED]
Date: 2003/11/28 Fri AM 11:14:25 CST
To: [EMAIL PROTECTED]
Subject: Please analyze my project table design
Greetings, my hands on school project is a small real estate database.
I am using MySQL 3.23 without InnoDB, but would like to migrate to 4.x
w/InnoDB at some point.
I would greatly appreciate any feedback on this design.
One quick comment---there appear to be many columns in common between the tables
representing people playing different roles (e.g. names, phone numbers).
Maybe you could create a single person table instead?
I don't know of a DB theory rule that says it's a bad idea to have the same columns in
many tables, but it might make the design more compact to take the common stuff and
put it into one table.
These are the business rules:
1) 1 matter may have several vendors and/or several purchasers
2) 1 matter will have 1 lawyer and 1 agent
Thank you for any advice!
CREATE TABLE other_lawyers (
other_lawyer_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
other_lawyer_fname VARCHAR(25) NULL,
other_lawyer_lname VARCHAR(25) NULL,
other_lawyer_email VARCHAR(25) NULL,
other_lawyer_address VARCHAR(50) NULL,
other_lawyer_city VARCHAR(15) NULL,
other_lawyer_provice VARCHAR(15) NULL,
other_lawyer_postal VARCHAR(6) NULL,
other_lawyer_phone VARCHAR(10) NULL,
other_lawyer_fax VARCHAR(10) NULL,
other_lawyer_firm VARCHAR(40) NULL,
PRIMARY KEY(other_lawyer_id)
);
CREATE TABLE agents (
agent_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
agent_fname VARCHAR(25) NULL,
agent_lname VARCHAR(25) NULL,
agent_email VARCHAR(25) NULL,
agent_address VARCHAR(50) NULL,
agent_city VARCHAR(15) NULL,
agent_provice VARCHAR(15) NULL,
agent_postal VARCHAR(6) NULL,
agent_phone VARCHAR(10) NULL,
agent_fax VARCHAR(10) NULL,
agent_agency VARCHAR(40) NULL,
PRIMARY KEY(agent_id)
);
CREATE TABLE matters (
file_number SMALLINT UNSIGNED NOT NULL,
agents_agent_id INTEGER UNSIGNED NOT NULL,
other_lawyers_other_lawyer_id INTEGER UNSIGNED NOT NULL,
sale_or_purchase ENUM('s','p') NULL,
property_address VARCHAR(50) NULL,
property_city VARCHAR(15) NULL,
property_province VARCHAR(15) NULL,
price FLOAT(8,2) NULL,
file_open_date DATE NULL,
file_posession_date DATE NULL,
PRIMARY KEY(file_number),
INDEX matters_FKIndex1(other_lawyers_other_lawyer_id),
INDEX matters_FKIndex2(agents_agent_id)
);
CREATE TABLE vendors (
vendor_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
matters_file_number SMALLINT UNSIGNED NOT NULL,
vendor_fname VARCHAR(25) NULL,
vendor_lname VARCHAR(25) NULL,
vendor_email VARCHAR(25) NULL,
vendor_address VARCHAR(50) NULL,
vendor_city VARCHAR(15) NULL,
vendor_provice VARCHAR(15) NULL,
vendor_phone_home VARCHAR(10) NULL,
vendor_phone_work VARCHAR(10) NULL,
vendor_postal VARCHAR(6) NULL,
vendor_fax VARCHAR(10) NULL,
vendor_firm VARCHAR(40) NULL,
PRIMARY KEY(vendor_id),
INDEX vendors_FKIndex1(matters_file_number)
);
CREATE TABLE purchasers (
purchasers_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
matters_file_number SMALLINT UNSIGNED NOT NULL,
purchaser_fname VARCHAR(25) NULL,
purchaser_lname VARCHAR(25) NULL,
purchaser_email VARCHAR(25) NULL,
purchaser_address VARCHAR(50) NULL,
purchaser_city VARCHAR(15) NULL,
purchaser_provice VARCHAR(15) NULL,
purchaser_phone_home VARCHAR(10) NULL,
purchaser_phone_work VARCHAR(10) NULL,
purchaser_postal VARCHAR(6) NULL,
purchaser_fax VARCHAR(10) NULL,
purchaser_firm VARCHAR(40) NULL,
PRIMARY KEY(purchasers_id),
INDEX purchasers_FKIndex1(matters_file_number)
);
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Re: Please analyze my project table design
From: David T-G [EMAIL PROTECTED] Date: 2003/11/28 Fri PM 03:49:17 CST To: mysql users [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Please analyze my project table design -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! ...and then [EMAIL PROTECTED] said... % ... % I don't know of a DB theory rule that says it's a bad idea to have the same columns in many tables, but it might make the design more compact to take the common stuff and put it into one table. Oh, there is, indeed. CF normalization :-) Well of course, but that begs the question, which normal form? HTH HAND good luck Paul :-D - -- David T-G * There is too much animal courage in (play) [EMAIL PROTECTED] * society and not sufficient moral courage. (work) [EMAIL PROTECTED] -- Mary Baker Eddy, Science and Health http://justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE/x8LcGb7uCXufRwARAq2vAKCDgl6tAoZyQMxRcuweK4fPFO8flQCfT1QU pJXdxLO02cnospbngiqMqzI= =eKBn -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Re[3]: Please analyze my project table design
From: Stefan Hinz [EMAIL PROTECTED] Date: 2003/11/28 Fri PM 04:45:24 CST To: [EMAIL PROTECTED] CC: David T-G [EMAIL PROTECTED], mysql users [EMAIL PROTECTED] Subject: Re[3]: Please analyze my project table design % I don't know of a DB theory rule that says it's a bad idea to have the same columns in many tables, but it might make the design more compact to take the common stuff and put it into one table. Oh, there is, indeed. CF normalization :-) Well of course, but that begs the question, which normal form? 1, 2, and 3. There's an abundance of explanations on E. F. Codd's normal forms on the web; I just picked the first Google result: Again, which normal form? There are three main normal forms, each with increasing levels of normalization: 2.1 First Normal Form (1NF): Each field in a table contains different information. For example, in an employee list, each table would contain only one birthdate field. But he never gave any indication that that's an issue. 2.2 Second Normal Form (2NF): No field values can be derived from another field. For example, if a table already included a birthdate field, it could not also include a birth year field, since this information would be redundant. But he never gave any indication that that's an issue. 2.3 Third Normal Form (3FN): No duplicate information is permitted. So, for example, if two tables both require a birthdate field, the birthdate information would be separated into a separate table, and the two other tables would then access the birthdate information via an index field in the birthdate table. Any change to a birthdate would automatically be reflect in all tables that link to the birthdate table. Right, that's *nominally* possible with the tables he gave, but the chance that a particular person is both an agent and a lawyer (or whatever) is probably about zero. So the _true_ redundancy is not very much at all. Which is why I asked: how does it violate normalization rules? And I mean in a practical sense, not in a well, perhaps some single person *could* be both a laywer and an agent sense. And I'm not disagreeing that he shouldn't combine the fields into a single table. It's just not obvious why it follows from normalization considerations. http://www.databaseanswers.com/normal_forms.htm If you're ambitious, you might want to try to abide by the other 330 requirements for relational databases as well, but in most cases, NF 1 through 3 is sufficient: http://www.aisintl.com/case/olais/pb96/biblio.htm#Codd74 Regards, -- Stefan Hinz [EMAIL PROTECTED] iConnect GmbH http://iConnect.de Heesestr. 6, 12169 Berlin (Germany) Telefon: +49 30 7970948-0 Fax: +49 30 7970948-3 [filter fodder: sql, mysql, query] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: RE: Please analyze my project table design
From: Paul F [EMAIL PROTECTED] Date: 2003/11/28 Fri PM 04:35:04 CST To: 'mysql users' [EMAIL PROTECTED] Subject: RE: Please analyze my project table design Thanks guys. I thought that normalization would refer to redundant info not necessarily the same column names? I would further see the problem with the design if say phone_number in the agent table and lawyer table contained the same data, which of course they won't. I agree, which is why I continued to disagree/question the claim of the other posters that the issue is normalization. That being said, regardless of whether the design issue is ascribed to the (important) topic of normalization, what you should do is pretty clear. As Stefan Hinz put it: All information that is specific for agents only would go to the agent table, and ditto for the lawyer table. All _kinds_ of information both have in common would go to the contact table. I thought about the persons table instead however you might notice that there are some columns that each do not have. Ie. home and work numbers for vendors and purchasers, firm for lawyers etc. Also I am expecting several columns to be NULL values for vendors and purchasers but not the other persons. Right. But note that the advice of Stefan that I quoted above implicitly addresses these concerns. I am very concerned with how I have setup the PK/FK/indices! Hmm... Well, PK indices are really not all that hard. FK indices are trickier, insofar as not all versions of MySQL have them implemented. But if you get stumped, just write up a proposed set of table designs (in accordance with the principles Stefan listed), and people here (or at USENET comp.database(s).*, if I recall correctly) would be able to help you. Thanks guys! The repeated column names for example phone_number -Original Message- From: David T-G [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2003 3:49 PM To: mysql users Cc: [EMAIL PROTECTED] Subject: Re: Please analyze my project table design -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! ...and then [EMAIL PROTECTED] said... % ... % I don't know of a DB theory rule that says it's a bad idea to have the same columns in many tables, but it might make the design more compact to take the common stuff and put it into one table. Oh, there is, indeed. CF normalization :-) HTH HAND good luck Paul :-D - -- David T-G * There is too much animal courage in (play) [EMAIL PROTECTED] * society and not sufficient moral courage. (work) [EMAIL PROTECTED] -- Mary Baker Eddy, Science and Health http://justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE/x8LcGb7uCXufRwARAq2vAKCDgl6tAoZyQMxRcuweK4fPFO8flQCfT1QU pJXdxLO02cnospbngiqMqzI= =eKBn -END PGP SIGNATURE- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Fwd: different between index and key when create table
From: Vivian Wang [EMAIL PROTECTED] Date: 2003/09/02 Tue PM 02:16:26 CDT To: [EMAIL PROTECTED] Subject: Fwd: different between index and key when create table mysql: Can anyone tell me what is different between index and key when creating table? like this situation: create table info ( fname char(9), lname char (15), address char(30), index(lname)); or create table info ( fname char(9), lname char(15), address char(30), key(lname)); Thanks. From the online manual: KEY is normally a synonym for INDEX. From version 4.1, the key attribute PRIMARY KEY may also be specified as just KEY. This was implemented for compatibility with other databases. See: http://www.mysql.com/doc/en/CREATE_TABLE.html Note that in DB *theory*, however, keys and indexes are not the same. sjfromm -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: RE: Books advice
Paul's book is long, but like good code, it's modular, so the length isn't an issue. From: Jeffery C. Baldwin [EMAIL PROTECTED] Date: 2003/08/04 Mon AM 11:14:29 CDT To: 'Paul DuBois' [EMAIL PROTECTED], 'Asif Iqbal' [EMAIL PROTECTED], 'Ralph Guzman' [EMAIL PROTECTED] CC: 'Fawad Siddiqui' [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Books advice Just to drop my $.02 in on this.. I started reading the 1st version of Pauls' MySQL book online a week or so back using my account over at 'Safari', once I read a little and decided that I was genuinely interested in this MySQL 'thing', I went over to Barnes and Noble with intentions of getting a hard copy of the 2nd edition of this book.. well.. I ended up leaving the store with a copy of 'Mastering MySQL' by Sybex instead. I returned that book yesterday and picked up the 2nd Edition of MySQL :-). I initially chose the 'Mastering MySQL' book pretty much due to one reason, and that the size of the MySQL' book was a little intimidating. But once I got home and started reading the Sybex book I realized why Pauls' book is so long, it is impossible to cover the amount of content necessary to get a good grasp for Mysql without using a lot of paper :-). The Sybex book made a lot of assumptions and didn't go into what I felt was very thorough detail on any subject (my idea is that this is a great book for the experienced DB admin), while Paul takes the time to explain each subject and every detail very thoroughly. Thanks Paul, I just started this book but I'm already very impressed. Again.. all of this is just my $.02 and I am VERY new at all of this DB stuff Jeff +---+ | Jeffery C Baldwin | Computer Consultant II | | University of North Carolina - Chapel Hill | 213 Miller Hall | CB# 1105 | Chapel Hill, NC 27599 | | Phone: (919) 843-2725 | Fax: (919) 966-8928 | E-Mail: jeff_baldwin at unc dot edu +---+ -Original Message- From: Paul DuBois [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 12:02 PM To: Asif Iqbal; Ralph Guzman Cc: 'Fawad Siddiqui'; [EMAIL PROTECTED] Subject: RE: Books advice At 21:04 -0400 7/31/03, Asif Iqbal wrote: I just ordered this book MySQL The definitive guide to using, programming, and administering MySQL 4 by Paul Dubois I found it more technical than MySQL cook book by Paul Dubois Comparison information: http://www.kitebird.com/mysql-book-comparison.php This page also includes links to each book's home page that provides other information about the book such as ISBN. On Thu, 31 Jul 2003, Ralph Guzman wrote: Here are two other books that I would recommend, specially the first one: * SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL by Michael J. Hernandez, John L. Viescas Joe Celko's SQL for Smarties: Advanced SQL Programming by Joe Celko -Original Message- From: Fawad Siddiqui [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 5:06 PM To: [EMAIL PROTECTED] Subject: Books advice Hi, I would like to learn about RDBMS, namely mysql of course, but know really nothing in this area, so have to learn about; RDBMS, SQL and mysql from scratch. In this regard, if anyone knows of any books they think would start me off on the right foot, I would be very grateful. I have done some searching on Amazon, with the following results. 1.Beginning Databases with MySQL by Richard Stones, Neil Matthew 2.MySQL Cookbook by Paul DuBois 3.Managing and Using MySQL by George Reese, et al 4.Inside Relational Databases by Mark Whitehorn, Bill Marklyn 5.Database Design by Ryan K. Stephens, Ronald R. Plew 6.The Practical SQL Handbook: Using SQL Variants by Judith S. Bowman, et al Many thanks in advance for all your help. Fawad -- Asif Iqbal http://pgpkeys.mit.edu:11371/pks/lookup?op=getsearch=0x8B686E08 There's no place like 127.0.0.1 -- Paul DuBois, Senior Technical Writer Madison, Wisconsin, USA MySQL AB, www.mysql.com Are you MySQL certified? http://www.mysql.com/certification/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Select with join query question
From: Richard Bolen [EMAIL PROTECTED] Date: 2003/07/28 Mon PM 01:37:27 CDT To: [EMAIL PROTECTED] Subject: Select with join query question I'm trying to write a select query that involves 2 tables. One table (Submissions) has a one to many relationship with the other table (Jobs). I'm trying to find all the records in Jobs that do NOT have a corresponding record in Submissions with a status of 1. The problem I'm having is that when there is more than one record in Submissions that match a record in Jobs and one Submissions record has a status of 1 and one record doesn't, my query matches the one with status != 1 and returns the record for Jobs (even though it has a record in Submissions with a status of 1 also). I haven't been able to think of a clever way to do it using only JOINs. Moreover, there are probably clever/elegant solutions using subselects (that is, nested queries), but your version of MySQL doesn't have those. Here's how I would do it. (Sorry if my notation deviates from yours a little): CREATE TEMPORARY TABLE tmp SELECT jobs.id AS jobs_id FROM jobs LEFT JOIN sub ON jobId=jobs.id WHERE status=1; SELECT jobs.id FROM jobs LEFT JOIN tmp ON jobs.id=jobs_id WHERE jobs_id IS NULL; I've tried a variety of queries including left outer joins and more simple join relationships. I'm using MySQL 3.23.47 on Windows. Here's an example query: select j.job_id from jobs j left outer join submissions s on (j.job_id = s.job_id) where s.status_id != 1 group by j.job_id Any help is greatly appreciated. Rich -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Re: Select with join query question
[snip] Rich's solution, which I edited out, was a good one. But, if you really want to do it with a single JOIN, try this: select j.* FROM Jobs j LEFT JOIN Submissions s ON j.jobid = s.jobid GROUP BY /* all selected columns */ HAVING min(abs(s.status - 1)) 0 I leave it as an exercise to the reader to figure out why this works (if it does -- I haven't tested it!). If status = 1 is the lowest possible value for status, you can simplify this a bit. A quick test seems to show it works. Though it doesn't pick up the case where status IS NULL, which occurs when there's a job but no matching submission. One disadvantage to your method: it requires computing a formula for each tuple, which slows things down (in principle; not sure it really matters in practice). Bruce Feist -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Database Design Question...
[snip] Let's say that I have users Mary, Joe, Frank, and Dan. I also have servers panther, cheetah, jaguar and lion. The data for each account that I want to maintain is UID, GID, home directory, and default shell. In designing a table or tables to handle this example what can I make as a primary key? My idea was to have a table named mary, with a row With the name mary, are you implying a separate table for each user? If so, that doesn't sound right. I think you should have three tables: (1) A table of users, with properties that depend on the user but not those that might vary with server; (2) A table of servers, with properties that are indepedent of users; (3) A table with primary key formed by a pair of foreign keys, one pointing at the user table, one at the server table. This table would have properties that depend on the user/server combination. (An example would be the shell, since presumably a user could have different shells on different servers.) for each server, and each column would hold the data such as UID, GID, etc. This would mean that the primary key for each row would simply be the server name. By holding all of the data, including server name, in a single table, I am not sure how I would define a primary key. I couldn't use the user name or server name as there would be duplication. I suppose I could use a dummy numeric field that is auto-incrementing, but I am not sure how good an idea this is. I think I have read somewhere that you can actually use a combination of multiple columns as a primary key or index, but this is something I am obviously not familiar with. One other concern I have is regarding performance. The database work I have done so far has been dealing with relatively miniscule amounts of data. This database table however is going to contain information for about 80 servers with somewhere around 300 users per server on average. This is quite a large number of rows from my very limited experience. I Nah, doesn't sound like much data to me. don't want to come up with a poor table design that ends up causing problems down the line. [snip] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: URGENT: Problems compiling mysql 3 and 4 on IRIX indy 6.5 IP22 mips
Look at http://gcc.gnu.org/ml/gcc-bugs/2000-11/msg00293.html
(I don't know anything about this, but that page seems very relevant.)
-S
From: Jason Buchanan [EMAIL PROTECTED]
Date: 2003/06/04 Wed AM 08:22:29 CDT
To: [EMAIL PROTECTED]
Subject: URGENT: Problems compiling mysql 3 and 4 on IRIX indy 6.5 IP22 mips
hi,
I'm having a hard time getting mysql 4 and mysql 3 to compile on IRIX 6.5...
Does anyone have a solution to this?
Below is an example of compiling mysql 4.0.13 (looks practically
identical for mysql 3.23.56):
g++ -DUNDEF_THREADS_HACK -I. -I. -I.. -I./../include -I../include -I./..
-I.. -I.. -O -DDBUG_OFF -D_BOOL -c -o mysql.o `test -f mysql.cc ||
echo './'`mysql.cc
In file included from
/usr/local/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/include/curses.h:5,
from mysql.cc:54:
/usr/include/curses.h:112: syntax error before `,'
/usr/include/curses.h:143: syntax error before `;'
/usr/include/curses.h:285: `__curses_bool_t' was not declared in this scope
/usr/include/curses.h:285: warning: `_meta' initialized and declared
`extern'
/usr/include/curses.h:301: type specifier omitted for parameter
/usr/include/curses.h:340: syntax error before `('
/usr/include/curses.h:388: type specifier omitted for parameter
/usr/include/curses.h:390: type specifier omitted for parameter
In file included from
/usr/local/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/include/curses.h:5,
from mysql.cc:54:
/usr/include/curses.h:856: type specifier omitted for parameter
/usr/include/curses.h:859: type specifier omitted for parameter
/usr/include/curses.h:860: type specifier omitted for parameter
/usr/include/curses.h:861: type specifier omitted for parameter
/usr/include/curses.h:862: type specifier omitted for parameter
/usr/include/curses.h:863: type specifier omitted for parameter
/usr/include/curses.h:864: type specifier omitted for parameter
/usr/include/curses.h:1015: type specifier omitted for parameter
make[2]: *** [mysql.o] Error 1
make[2]: Leaving directory `/usr/people/jsb/mysql-4.0.13/client'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/people/jsb/mysql-4.0.13'
make: *** [all] Error 2
Thanks,
Jason
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: C API
From: [EMAIL PROTECTED]
Date: 2003/06/03 Tue AM 11:45:31 CDT
To: [EMAIL PROTECTED]
Subject: C API
Hello,
I'm trying to code a small C client, under windows, with bloddshed Dev-C++,
and i always get an error.
/* Code */
#include conio.h
#include stdarg.h
#include winsock.h
#include stdio.h
#include stdlib.h
#include string.h
#include mysql.h
My experience is that one should always include these files:
#include my_global.h
#include my_sys.h
#include mysql.h
This is just a stab in the dark, though.
-S
int main(void) {
MYSQL* toto;
toto = mysql_init(toto);
}
/* this is the compler log */
Compiler: Default compiler
Executing gcc.exe...
gcc.exe U:\mep\Dev\abr.c -o U:\mep\Dev\abr.exe
-IC:\Dev-Cpp\include -IC:\mysql\include -LC:\Dev-Cpp\lib
C:\DOCUME~1\badier1\LOCALS~1\Temp/ccW8.o(.text+0x1d2):abr.c: undefined
reference to [EMAIL PROTECTED]'
Execution terminated
I really don't know where this can come from. I downloaded the latest
production mysql server (to get the client and libraries), but nothing i
tried correct the problem.
Any idea?
Thanks
Vincent
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
