wrong merging + use of column names of table as fields

[ilektro]

I unfortunately still have to come back to this issue (from an old post and a Ticket 18906 you have opened):

the merging from the data is incorrect:
- mail addresses imported via dbase with 18 fields, well defined
- all looks perfect in the recipients tab
- when email arrives at test addresses in database, the info from that fields that is merged is wrong
- the info in the recipients tab still looks fine

I have downloaded the latest version, hoping that this had now been solved.

+

The column names cannot be used as field names and as a result I can only run 1 maillist on the program (so I am still using another program on Parallels Windows - Kristanix - for all the rest of my imported databases) but that doesn't have the possibility to include IF / ELSE statements.

I still hope that there is a solution as I have looked at all other Mac solutions but only Windows solutions are able to cope with all this. Or otherwise I will be doomed to use online tools on a pay per sent mail basis

I cross fingers!

 

[stanbusk]

Are you the one that has problems with importing from mySQL an d I finally found out it was because your mySQL fields where including tabs?

 

[ilektro]

indeed but I see no tabs in the database so I have no idea what I would need to do or how to remove them

the field that causes it has *bxl*ght*antw* in it

it's also strange that the same import into another program doesn't cause this issue, no?

 

[stanbusk]

Well, it depends on the program. With MaxBulk Mailer a tab means next fields, wherever it is found in the field, including if surrounded with quotes.

 

[ilektro]

ok, but how to get them out of a database when the only thing I see in the field of the table is "*bxl*gnt*antw*" ? I also checked the php code and at no point there is a tab added. Moreover, how would I know that there is a tab in a field with future tables I import when it's not visible in the table? And how come that it does look good on the recipient screen (so all is in the correct columns) yet people still receive mails with wrong data?

following my last newsletter I received over 60 mails from people saying links don't work (eg unsubscribe link that contains fields from the database)

 

[stanbusk]

About links that don't work, are using MLM and click-tracking?

The best way to avoid tabs in fields is not adding them in the fist place. I don't explain myself how you did it. How did you generate that mySQL database? HTML forms would not let you add tabs to fields.

 

[ilektro]

the table is generated by an html form that at no point ads tabs
I do not work with MLM, I insert links eg http://www.xxx.com/?p=ID&c=PASS etc

 

[stanbusk]

If you do not use MLM then MaxBulk Mailer is not the culprit here since your message text is sent as is with no modifications.

About the table generation, I don't explain myself how you have tabs then, when using a form the tab is to switch between the form controls so it is never added to the field.

 

[ilektro]

The message text is clearly not sent "as is" because I get mails where the ID in some cases is 0 where it should be the ID coming from the database. (this happens to many fields so FIRSTNAME "David" is suddenly "Belgium" = COUNTRY. The data (merging) is not consistent and there is no consistency check. If it were visible in the recipients list of MBM, then I would at least see that there IS an issue and where the issue is but the recipient list shows no errors as if the import happened perfectly.

If the issue would be due to the tabs - which I can understand - then it should be for every mail as I use the field with tabs for every email address. So :

- either it should be visible that the import "failed" > which is not the case
- or during sending it should highlight that the fields change place
- or I would need to be able to see in the dbase that there is tabs but I have checked with different programmers and according to them there is NO tabs that are added in the form (I'm one of those programmers as I'm a webmaster since 1997)

I can send you an sql file if it helps for you to test the import? The issue is that you would need to send out the mail in order to see the error as the error is in the merging, not the import.