RE: [ODBC] Re: [HACKERS] Release in 2 weeks ...
-Original Message- From: Hiroshi Inoue [mailto:[EMAIL PROTECTED]] Sent: 01 March 2001 02:05 To: Patrick Welche Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ODBC] Re: [HACKERS] Release in 2 weeks ... Patrick Welche wrote: On Wed, Feb 28, 2001 at 08:53:31AM +0900, Hiroshi Inoue wrote: ... I think I've fixed this bug at least for MS-Access. You could get the latest win32 driver from ftp://ftp.greatbridge.org/pub/pgadmin/stable/psqlodbc.zip . Please try it. How can I just install that file? (ie., M$ Access - psqlodbc.dll - real OS) I don't know if M$-access requires MDAC now(it didn't require MDAC before). I use ADO and don't use M$-access other than testing. ADO requires MDAC and pgAdmin uses ADO AFAIK. Yes, pgAdmin does use MDAC, currently v2.6 = aside: I just tried installing pgAdmin - the installer says: This setup requires at least version 2.5 of the Microsoft Data Access Components (MDAC) to be installed first. If the MDAC installer (mdac_typ.exe) is not provided with this setup, you can find it on the Microsoft web site (www.microsoft.com) And after searching said website, http://www.microsoft.com/data/download2.htm shows: Microsoft Data Access Components MDAC 2.1.1.3711.11 2.5... I can see the following at http://www.microsoft.com/data/download.htm Data Access Components (MDAC) redistribution releases. Five releases of MDAC are available here: The new MDAC 2.6, two of MDAC 2.5, and two of MDAC 2.1. You can The message stating that you need MDAC 2.5 is generated by the MS Installer - I cannot change. The pgAdmin notes on the website (which I wrote) recommend v2.6 of MDAC which is indeed available at www.microsoft.com/data/ Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [ODBC] Re: [HACKERS] Release in 2 weeks ...
On Wed, Feb 28, 2001 at 08:53:31AM +0900, Hiroshi Inoue wrote: ... I think I've fixed this bug at least for MS-Access. You could get the latest win32 driver from ftp://ftp.greatbridge.org/pub/pgadmin/stable/psqlodbc.zip . Please try it. How can I just install that file? (ie., M$ Access - psqlodbc.dll - real OS) = aside: I just tried installing pgAdmin - the installer says: This setup requires at least version 2.5 of the Microsoft Data Access Components (MDAC) to be installed first. If the MDAC installer (mdac_typ.exe) is not provided with this setup, you can find it on the Microsoft web site (www.microsoft.com) And after searching said website, http://www.microsoft.com/data/download2.htm shows: Microsoft Data Access Components MDAC 2.1.1.3711.11 2.5... Cheers, Patrick ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] WAL RC1 status
I am *not* feeling good about pushing out an RC1 release candidate
today.
I've been going through the WAL code, trying to understand it and
document it. I've found a number of minor problems and several major
ones ("major" meaning "can't really fix without an incompatible file
format change, hence initdb"). I've reported the major problems to
the mailing lists but gotten almost no feedback about what to do.
In addition, I'm still looking for the bug that I originally went in to
find: Scott Parish's report of being unable to restart after a normal
shutdown of beta4. Examination of his WAL log shows some pretty serious
lossage (see attached dump). My current theory is that the
buffer-slinging logic in xlog.c dropped one or more whole buffers' worth
of log records, but I haven't figured out exactly how.
I want to veto putting out an RC1 until these issues are resolved...
comments?
regards, tom lane
...
0/00599890: prv 0/00599854; xprv 0/00599854; xid 18871; RM 10 info 00 len 65
0/005998F4: prv 0/00599890; xprv 0/00599890; xid 18871; RM 11 info 90 len 50
0/00599948: prv 0/005998F4; xprv 0/005998F4; xid 18871; RM 1 info 00 len 4
commit: 2001-02-26 17:19:57
0/0059996C: prv 0/00599948; xprv 0/; xid 0; RM 0 info 00 len 32
checkpoint: redo 0/0059996C; undo 0/; sui 29; nextxid 18903; nextoid 35195;
online
-- this is the last normal-looking checkpoint record. Judging from the
-- commit timestamps surrounding prior checkpoints, checkpoints were
-- happening every five minutes approximately on the 5-minute mark, so
-- this one happened about 17:20. (There really should be a timestamp
-- in the checkpoint records...)
0/005999AC: prv 0/0059996C; xprv 0/; xid 18923; RM 10 info 08 len 8226; bkpb 1
0/0059B9FC: prv 0/005999AC; xprv 0/005999AC; xid 18923; RM 11 info 98 len 8226; bkpb 1
0/0059DA4C: prv 0/0059B9FC; xprv 0/0059B9FC; xid 18923; RM 10 info 00 len 72
0/0059DAB4: prv 0/0059DA4C; xprv 0/0059DA4C; xid 18923; RM 11 info 90 len 26
0/0059DAF0: prv 0/0059DAB4; xprv 0/0059DAB4; xid 18923; RM 10 info 00 len 72
0/0059DB58: prv 0/0059DAF0; xprv 0/0059DAF0; xid 18923; RM 11 info 90 len 26
0/0059DB94: prv 0/0059DB58; xprv 0/0059DB58; xid 18923; RM 10 info 00 len 72
0/0059DBFC: prv 0/0059DB94; xprv 0/0059DB94; xid 18923; RM 11 info 90 len 26
0/0059DC38: prv 0/0059DBFC; xprv 0/0059DBFC; xid 18923; RM 10 info 08 len 8226; bkpb 1
0/0059FC88: prv 0/0059DC38; xprv 0/0059DC38; xid 18923; RM 11 info 98 len 8226; bkpb 1
0/005A1CD8: prv 0/0059FC88; xprv 0/0059FC88; xid 18923; RM 1 info 00 len 4
commit: 2001-02-26 17:21:10
0/005A1CFC: prv 0/005A1CD8; xprv 0/; xid 18951; RM 15 info 00 len 100
0/005A1D80: prv 0/005A1CFC; xprv 0/005A1CFC; xid 18951; RM 10 info 00 len 72
0/005A1DE8: prv 0/005A1D80; xprv 0/005A1D80; xid 18951; RM 11 info 90 len 26
0/005A1E24: prv 0/005A1DE8; xprv 0/005A1DE8; xid 18951; RM 10 info 00 len 72
0/005A1E8C: prv 0/005A1E24; xprv 0/005A1E24; xid 18951; RM 11 info 90 len 26
0/005A1EC8: prv 0/005A1E8C; xprv 0/005A1E8C; xid 18951; RM 10 info 00 len 72
0/005A1F30: prv 0/005A1EC8; xprv 0/005A1EC8; xid 18951; RM 11 info 90 len 26
0/005A1F6C: prv 0/005A1F30; xprv 0/005A1F30; xid 18951; RM 10 info 00 len 72
0/005A1FD4: prv 0/005A1F6C; xprv 0/005A1F6C; xid 18951; RM 11 info 90 len 26
0/005A201C: prv 0/005A1FD4; xprv 0/005A1FD4; xid 18951; RM 10 info 00 len 65
0/005A2080: prv 0/005A201C; xprv 0/005A201C; xid 18951; RM 11 info 98 len 8226; bkpb 1
0/005A40D0: prv 0/005A2080; xprv 0/005A2080; xid 18951; RM 1 info 00 len 4
commit: 2001-02-26 17:21:33
0/005A40F4: prv 0/005A40D0; xprv 0/; xid 18986; RM 10 info 00 len 72
0/005A415C: prv 0/005A40F4; xprv 0/005A40F4; xid 18986; RM 11 info 90 len 26
0/005A4198: prv 0/005A415C; xprv 0/005A415C; xid 18986; RM 10 info 00 len 72
0/005A4200: prv 0/005A4198; xprv 0/005A4198; xid 18986; RM 11 info 90 len 26
0/005A423C: prv 0/005A4200; xprv 0/005A4200; xid 18986; RM 10 info 00 len 72
0/005A42A4: prv 0/005A423C; xprv 0/005A423C; xid 18986; RM 11 info 90 len 26
0/005A42E0: prv 0/005A42A4; xprv 0/005A42A4; xid 18986; RM 10 info 00 len 72
0/005A4348: prv 0/005A42E0; xprv 0/005A42E0; xid 18986; RM 11 info 90 len 26
0/005A4384: prv 0/005A4348; xprv 0/005A4348; xid 18986; RM 10 info 00 len 65
0/005A43E8: prv 0/005A4384; xprv 0/005A4384; xid 18986; RM 11 info 90 len 50
0/005A443C: prv 0/005A43E8; xprv 0/005A43E8; xid 18986; RM 1 info 00 len 4
commit: 2001-02-26 17:22:20
0/005A4460: prv 0/005A443C; xprv 0/; xid 19020; RM 10 info 00 len 72
0/005A44C8: prv 0/005A4460; xprv 0/005A4460; xid 19020; RM 11 info 90 len 26
0/005A4504: prv 0/005A44C8; xprv 0/005A44C8; xid 19020; RM 10 info 00 len 72
0/005A456C: prv 0/005A4504; xprv 0/005A4504; xid 19020; RM 11 info 90 len 26
0/005A45A8: prv 0/005A456C; xprv 0/005A456C; xid 19020; RM 10 info 00 len 72
0/005A4610: prv 0/005A45A8; xprv 0/005A45A8; xid 19020; RM 11 info 90 len 26
0/005A464C: prv 0/005A4610; xprv 0/005A4610; xid 19020; RM 10 info 00 len 72
0/005A46B4: prv
Re: [HACKERS] WAL RC1 status
On Fri, 2 Mar 2001, Tom Lane wrote:
I am *not* feeling good about pushing out an RC1 release candidate
today.
I've been going through the WAL code, trying to understand it and
document it. I've found a number of minor problems and several major
ones ("major" meaning "can't really fix without an incompatible file
format change, hence initdb"). I've reported the major problems to
the mailing lists but gotten almost no feedback about what to do.
In addition, I'm still looking for the bug that I originally went in to
find: Scott Parish's report of being unable to restart after a normal
shutdown of beta4. Examination of his WAL log shows some pretty serious
lossage (see attached dump). My current theory is that the
buffer-slinging logic in xlog.c dropped one or more whole buffers' worth
of log records, but I haven't figured out exactly how.
I want to veto putting out an RC1 until these issues are resolved...
comments?
Will second it ... Vadim is supposed to be back on the 6th, and Peter has
a couple of changes to configure he wants to do this weekend for the JDBC
stuff ... Thomas and I are in SF the end of next week for some meetings,
so if you can pop off a summary of what you've found to either of us, and
assuming that Vadim doesn't get caught up by then, we can bring them up
"in person" at that time ... ?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] WAL RC1 status
I am *not* feeling good about pushing out an RC1 release candidate
today.
I've been going through the WAL code, trying to understand it and
document it. I've found a number of minor problems and several major
ones ("major" meaning "can't really fix without an incompatible file
format change, hence initdb"). I've reported the major problems to
the mailing lists but gotten almost no feedback about what to do.
In addition, I'm still looking for the bug that I originally went in to
find: Scott Parish's report of being unable to restart after a normal
shutdown of beta4. Examination of his WAL log shows some pretty serious
lossage (see attached dump). My current theory is that the
buffer-slinging logic in xlog.c dropped one or more whole buffers' worth
of log records, but I haven't figured out exactly how.
I want to veto putting out an RC1 until these issues are resolved...
comments?
I was not sure how to respond. Requiring an initdb at this stage seems
like it could be a pretty major blow to beta testers. However, if we
will have 7.1 problems with WAL that can not be fixed without a file
format change, we will have problems down the road. Is there a version
number in the WAL file? Can we put conditional code in there to create
new log file records with an updated format?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] WAL RC1 status
Bruce Momjian [EMAIL PROTECTED] writes: Is there a version number in the WAL file? catversion.h will do fine, no? Can we put conditional code in there to create new log file records with an updated format? The WAL stuff is *far* too complex already. I've spent a week studying it and I only partially understand it. I will not consent to trying to support multiple log file formats concurrently. Well, I was thinking a few things. Right now, if we update the catversion.h, we will require a dump/reload. If we can update just the WAL version stamp, that will allow us to fix WAL format problems without requiring people to dump/reload. I can imagine this would be valuable if we find we need to make changes in 7.1.1, where we can not require dump/reload. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] WAL RC1 status
Bruce Momjian [EMAIL PROTECTED] writes: Is there a version number in the WAL file? catversion.h will do fine, no? Can we put conditional code in there to create new log file records with an updated format? The WAL stuff is *far* too complex already. I've spent a week studying it and I only partially understand it. I will not consent to trying to support multiple log file formats concurrently. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] WAL RC1 status
Bruce Momjian [EMAIL PROTECTED] writes: Well, I was thinking a few things. Right now, if we update the catversion.h, we will require a dump/reload. If we can update just the WAL version stamp, that will allow us to fix WAL format problems without requiring people to dump/reload. Since there is not a separate WAL version stamp, introducing one now would certainly force an initdb. I don't mind adding one if you think it's useful; another 4 bytes in pg_control won't hurt anything. But it's not going to save anyone's bacon on this cycle. At least one of my concerns (single point of failure) would require a change to the layout of pg_control, which would force initdb anyway. Anyone want to propose a third version# for pg_control? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] WAL RC1 status
Bruce Momjian [EMAIL PROTECTED] writes: Well, I was thinking a few things. Right now, if we update the catversion.h, we will require a dump/reload. If we can update just the WAL version stamp, that will allow us to fix WAL format problems without requiring people to dump/reload. Since there is not a separate WAL version stamp, introducing one now would certainly force an initdb. I don't mind adding one if you think it's useful; another 4 bytes in pg_control won't hurt anything. But it's not going to save anyone's bacon on this cycle. Having a version number of binary files has saved me many times because I can add a little 'if' to allow upward binary compatibility without breaking old binary files. I think we should have one. I see our btree files, but I don't see one in heap. I am going to recommend that for 7.2. All our files should have versions just in case we ever need it. Some day, we may be able to skip dump/reload for major versions. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] WAL RC1 status
I've been going through the WAL code, trying to understand it and
document it. I've found a number of minor problems and several major
ones ("major" meaning "can't really fix without an incompatible file
format change, hence initdb"). I've reported the major problems to
the mailing lists but gotten almost no feedback about what to do.
Sorry for the "no feedback", but I've assumed that this will be more
productively discussed with Vadim in the loop. I don't disagree with
your observations, but of course that is from a position of happy
ignorance :)
... I want to veto putting out an RC1 until these issues are resolved...
comments?
OK with me.
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
RE: [HACKERS] WAL RC1 status
From: Bruce Momjian [SMTP:[EMAIL PROTECTED]] Sent: Friday, March 02, 2001 9:54 AM To: Tom Lane Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [HACKERS] WAL RC1 status Bruce Momjian [EMAIL PROTECTED] writes: Is there a version number in the WAL file? catversion.h will do fine, no? Can we put conditional code in there to create new log file records with an updated format? While it may be unfortunate to have to do an initdb at this point in the beta cycle, it is a beta and that is part of the deal. Postgre has the reputation of being the highest quality opensource database and we should do nothing to tarnish that. Release it when it's ready and not before. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [ODBC] Re: [HACKERS] Release in 2 weeks ...
I've got a clue for ApplixWare, if you happen to have that package (US$90). Please post it, Thomas. I got nowhere following their instructions. Have you looked at *our* instructions in the chapter on ODBC? I haven't done much with it in quite a while, but afaik it all should still work. I would have expected Cary O'Brien (sp? name?? Done from memory: sorry "aka Cary" :/ to have spoken up if things have broken, so the instructions should still be good. - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Attribute Alignment
On Sun, Dec 17, 2000 at 06:03:34PM -0500, Michael Richards wrote: Having written this tool which is at least the basis for a complete table data verification program (it's written in c++) I'm wondering if there is any chance of having it pointed to, linked to or otherwise made available? Time-permitting I may add to it in the future, although I hope I'll never have to use it again :) Anyone have this code/tool Michael is talking about? I tried to contact him directly, but one of his emails bounces, and the other has not responded. Ross ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] WAL RC1 status
On Fri, Mar 02, 2001 at 10:54:04AM -0500, Bruce Momjian wrote: Bruce Momjian [EMAIL PROTECTED] writes: Is there a version number in the WAL file? catversion.h will do fine, no? Can we put conditional code in there to create new log file records with an updated format? The WAL stuff is *far* too complex already. I've spent a week studying it and I only partially understand it. I will not consent to trying to support multiple log file formats concurrently. Well, I was thinking a few things. Right now, if we update the catversion.h, we will require a dump/reload. If we can update just the WAL version stamp, that will allow us to fix WAL format problems without requiring people to dump/reload. I can imagine this would be valuable if we find we need to make changes in 7.1.1, where we can not require dump/reload. It Seems to Me that after an orderly shutdown, the WAL files should be, effectively, slag -- they should contain no deltas from the current table contents. In practice that means the only part of the format that *should* matter is whatever it takes to discover that they really are slag. That *should* mean that, at worst, a change to the WAL file format should only require doing an orderly shutdown, and then (perhaps) running a simple program to generate a new-format empty WAL. It ought not to require an initdb. Of course the details of the current implementation may interfere with that ideal, but it seems a worthy goal for the next beta, if it's not possible already. Given the opportunity to change the current WAL format, it ought to be possible to avoid even needing to run a program to generate an empty WAL. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] WAL RC1 status
It Seems to Me that after an orderly shutdown, the WAL files should be, effectively, slag -- they should contain no deltas from the current table contents. In practice that means the only part of the format that *should* matter is whatever it takes to discover that they really are slag. That *should* mean that, at worst, a change to the WAL file format should only require doing an orderly shutdown, and then (perhaps) running a simple program to generate a new-format empty WAL. It ought not to require an initdb. Of course the details of the current implementation may interfere with that ideal, but it seems a worthy goal for the next beta, if it's not possible already. Given the opportunity to change the current WAL format, it ought to be possible to avoid even needing to run a program to generate an empty WAL. This was my question too. If we are just changing WAL, why can't we just have them stop the postmaster, install the new binaries, and restart. Tom told me on the phone that there was a magic number in the WAL log file, and I see it now: #define XLOG_PAGE_MAGIC 0x17345168 Couldn't we just have our new beta ignore WAL pages with this entry, knowing that startup/shutdown creates new WAL files anyway, Aside from inconveniencing the beta users, people can do testing easier if we don't require a dump/reload for every WAL format change. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Turkish locale bug
Sezai YILMAZ [EMAIL PROTECTED] writes: Justin Clift wrote: Tom Lane wrote: Sezai YILMAZ [EMAIL PROTECTED] writes: With Turkish locale it is not possible to write SQL queries in CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first are downgraded to "nsert" and Then "nsert" and "unon" does not match as SQL identifier. Ugh. snip How about thinking in the other direction is it possible for PostgreSQL to be able to recognised localised versions of SQL queries? i.e. For a Turkish locale it associates "nsert" INSERT and "unon" with UNION. I don't have any opinion how can solve this problem. But, I don't agree with this solution. SQL is naturally English. I am against SQL to be localized. Has anyone come up with a good solution? The last one I saw from Tom Lane required compile-time options which isn't an option for us. -- Trond Eivind Glomsrd Red Hat, Inc. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: Turkish locale bug
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Has anyone come up with a good solution? The last one I saw from Tom Lane required compile-time options which isn't an option for us. As far as I know it's fixed in the currently-committed sources. The key is to do case normalization for keyword-testing separately from case normalization of an identifier (after it's been determined not to be a keyword). Amazingly enough, SQL99 actually requires this... In Turkish this means that either INSERT or insert will be seen as a keyword, while either XINSERT or xinsert will become "xýnsert". regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Turkish locale bug
I said: In Turkish this means that either INSERT or insert will be seen as a keyword, while either XINSERT or xinsert will become "xýnsert". Sheesh. Gotta think twice before pressing SEND. That should be INSERT - keyword insert - keyword XINSERT - "xýnsert" xinsert - "xinsert" since of course the issue is the lowercase transform of "I". regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] WAL RC1 status
[EMAIL PROTECTED] (Nathan Myers) writes: It Seems to Me that after an orderly shutdown, the WAL files should be, effectively, slag -- they should contain no deltas from the current table contents. In practice that means the only part of the format that *should* matter is whatever it takes to discover that they really are slag. That *should* mean that, at worst, a change to the WAL file format should only require doing an orderly shutdown, and then (perhaps) running a simple program to generate a new-format empty WAL. It ought not to require an initdb. Excellent point, considering that we were already thinking of making a handy-dandy little utility to remove broken WAL files... Shouldn't take much more than that to build something that also reformats pg_control. Thanks for the suggestion! regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
