Re: [PHP-DB] csv problem.. read csv from var
2007/2/16, bedul [EMAIL PROTECTED]:
i have problem with reading csv.. for i know the example script i get was
BASIC SCRIPT=
$handle = fopen(hasillab.csv, r);
$data2=$handle;
while($data = fgetcsv($handle, 1000, ,)){
foreach($data as $str)
$data2.=br= .$str;
}
the result was:
==OUTPUT==
= A507257
= 3/2/2007
= Hematologi Lengkap,Cholesterol Total,LDL Cholesterol,Trigliserida,HDL
Cholesterol
hasillab.csv contain
A507257,3/2/2007,Hematologi Lengkap,Cholesterol Total,LDL
Cholesterol,Trigliserida,HDL Cholesterol,Asam Urat,Gula Darah Puasa,Gula
Darah 2 Jam PP,Kreatinin,Ureum,Bilirubin Total,Alkali
Fosfatase,SGOT,SGPT,Urine Lengkap,Feses Rutin,Darah Samar Faeces,VDRL,Anti
-
HBs,Total PSA,HBsAg,Anti - HCV Total
the problem i have is.. how about the csv is a var
DATA===
$csv=
A507257,3/2/2007,\Hematologi Lengkap,Cholesterol Total,LDL
Cholesterol,Trigliserida,HDL Cholesterol,Asam Urat,Gula Darah Puasa,Gula
Darah 2 Jam PP,Kreatinin,Ureum,Bilirubin Total,Alkali
Fosfatase,SGOT,SGPT,Urine Lengkap,Feses Rutin,Darah Samar Faeces,VDRL,Anti
-
HBs,Total PSA,HBsAg,Anti - HCV Total\;
what should i do to make the ouput like above.
until now.. i try save the var into files then i use basic script to load
it
--
PHP Database Mailing List ( http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
You can parse the csv yourself. So, lets cast some regexp magic into the
emptyness of this mailing thread:
preg_match_all('/(?=^|,)((.|\n)*(?!)|.*)(,|$)/Um', $csv, $matches,
PREG_SET_ORDER);
$rows = array();
$fields = array();
foreach ($matches as $match) {
$field = $match[1];
if ($field != '' $field != '' $field[0] == ''
substr($field, -1) == '') {
$field = substr($field, 1, -1);
$field = str_replace('', '', $field);
}
$fields[] = $field;
if ($match[3] == '') {
$rows[] = $fields;
$fields = array();
}
}
$rows variable will be filled with an array for each row in a CSV format
complaint string, using line breaks as row separators and commas as field
separators.
If you wonder about the mystic forces that powers this regexp, I'll be more
than willing to explain them throughly, if time becomes available. If it
doesn't work (I tested it againts all the use cases I could think of, but...
murphy's law applies) go blame someone else... =P
Also, if you're working on PHP5, you may bring up the new, mostly unused,
spells in your PHP spell book, available to all those who have reached level
5 in PHP wizardry. Just copy paste (that skill you have probably adquired
in your early days as an apprentice) the code from the PHP manual included
as an example of custom stream wrappers:
http://www.php.net/stream_wrapper_register
With the VariableStream class registered as a stream wrapper, you can
magically use global variables as a streams. Therefore something like this
will work:
$csv=...etc...;
$handle = fopen(var://csv, r);
... etc ...
Re: [PHP-DB] Select distinct field won't return distinct value
I have a friend called GROUP_CONCAT, he may know what you want but he's only available since MySQL 4.1 2006/6/7, Blanton, Bob [EMAIL PROTECTED]: It is a Sybase vendor function but I was wondering if mysql had something comparable. I don't see anything in the manual. Maybe the subquery is the only way to go. -Original Message- From: Chris [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 8:50 AM To: Blanton, Bob Cc: php-db@lists.php.net Subject: Re: [PHP-DB] Select distinct field won't return distinct value Blanton, Bob wrote: I'm just learning MySQL so don't know all the syntax. There is a LIST function in Sybase Adaptive Server Anywhere which would do that. Is there an equivalent function in MySQL? Query: SELECT distinct niin, list(serial_number) FROM fmds.maintenance_equipment group by niin order by niin Output: niin list(serial_number) 000213909 B71-11649,B71-11657,B71-11650 000473750 BAF-3750-0001,BAF-3750-0002,BAF-3750-0003 000929062 2341 001139768 2207 Pretty sure that's a sybase specific function. Nothing like that exists in mysql or postgresql. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Sending filing attachments using PHP
2006/5/12, JupiterHost.Net [EMAIL PROTECTED]: Dwight Altman wrote: Right after rebuilding php and apache and breaking PHP funtionality for everyone, just so you can send a semi complex MIME message? That is the epitome of PHP's lameness and why I can't sit quietly by and not recommend an easy to install and use and maintain solution. This command breaks Apache? require(class.phpmailer.php); And besides its in a non strutcutered way to maek it even more impossible to maintain. Classes and Object Oriented Programming? Thanks Dwight, good info. I'm speaking in generalitites of working with PHP not specifics components of the technology. As an example of this general clutter/bloat/mess that PHPs basic paradigm is see: http://tnx.nl/php Disclaimer: Note that that url is a comparison of Perl to PHP, which is not what I'm saying in all this mess. Just look at each point of PHP and if you don't see whay iots so bad look at how Perl does it and hopefully it will make more clear where I'm coming from for at least part of my argument (the deve part) that PHP has many negatives things about it that are either not an issue in other langauges or are not nearly as pronounced or common to run up against. I'm very sorry if this makes some uncomfortable but note that I'm pointing out downfalls of PHP, a thing, I am not getting personal and would appreciate the same courtesy. (which Dwight and Edward have done, thanks ;p) -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php It's a fact that I can't deny any of the bad points you have exposed about PHP. I even agree with you that most of this problems are really awful and it's pointless to hide them. But the fact that PHP is by preference the language for developing small and middle web solutions aimed to be economic and rapidly developed is also undeniable. All languages have their pros and cons, and trying to compare them outside of the context of the target market is pointless. It just happens that PHP pros fit better the desires of the web solutions market, and they also don't care much about current PHP cons. Anyway, this market is evolving and its needs are changing, so it's normal for developers to try and anticipate future development needs and try to make PHP fit into other philosophies, methodologies or technologies it was not designed to work with, and everyone who has tried this (including me) have started to hate PHP in a certain way. But that's all there is to it, I hate not having a proper application framework, I hate not having namespaces, I hate the overhead of working with OOP, I hate magic quotes, but I still use PHP because it is still the most appropiate development enviroment for a small or middle sized web solution. I'm guessing this part, but I think you think alike and that's the reason you're still on this list and trying to make a point out of your bad experiences with PHP. We can still hope that this problems will be solved without harming the spirit of PHP in future versions or future enhacements, and that our needs will be somehow be heard. If not, well they will realize soon that current trends are leading to a different kind of solutions (not that utopic Web2.0 but a more realistic Web1.5). Thanks for sharing your opinion and concerns, I really appreciate them.
Re: [PHP-DB] Sending filing attachments using PHP
2006/5/12, Martin Alterisio [EMAIL PROTECTED]: ... I hate not having a proper application framework, ... Sorry, there is a mistake there. I meant to say that I hate not having an application server, although I also think currently available framework are just not the way to go. They are too big and produce too much overhead.
Re: [PHP-DB] Sending filing attachments using PHP
2006/5/12, JupiterHost.Net [EMAIL PROTECTED]:
It's a fact that I can't deny any of the bad points you have exposed
about
PHP. I even agree with you that most of this problems are really awful
and
it's pointless to hide them. But the fact that PHP is by preference the
language for developing small and middle web solutions aimed to be
economic
and rapidly developed is also undeniable. All languages have their pros
and
cons, and trying to compare them outside of the context of the target
market
is pointless. It just happens that PHP pros fit better the desires of
the
web solutions market, and they also don't care much about current PHP
cons.
Most people aren't aware of the cons, thats my point :)
Developers are aware (well most of them). Designers are not, project leaders
are not (with the exception of a few), marketing people are not, and all the
people higher up in the administration are not. This is mostly our fault,
there really aren't enough effort applied to educate those outside the IT
world.
For example:
If Mr. big wig was aware that phpBB has a history if being uber
hackable and even being used in a rootkit scheme a time or two he'd not
choose PHP. But its shiny so he says go with that it looks nice.
That is how its popularity has grown, ignorance of the facts.
Anyway, this market is evolving and its needs are changing, so it's
normal
for developers to try and anticipate future development needs and try to
make PHP fit into other philosophies, methodologies or technologies it
was
not designed to work with, and everyone who has tried this (including
me)
have started to hate PHP in a certain way. But that's all there is to
it, I
hate not having a proper application framework, I hate not having
namespaces, I hate the overhead of working with OOP, I hate magic
quotes,
but I still use PHP because it is still the most appropiate development
enviroment for a small or middle sized web solution.
Why not use Perl, it has all the pros but does not have the cons :)
Because it has cons, and lots of them. It's not a language who was designed
for web development and this becomes a hassle. Its language constructions
are not as intuitive as other languages, there are too many ways of doing
the same thing, and too many different code conventions (if they can be
called as such). So it really becomes complicate to make one perl developer
work with another perl developer. There are too many basic data structures
for a scripting language, PHP arrays work better in almost any situation,
are easier to understand and use. Debugging a perl application requires a
higher level of programming skills.
In fact, I use it for several high volumn websites:
- with persistent database connections and persistently running
instances of the script
(which is the *only* positive PHP has, except it means running PHP
as nobody and with really really bad permissions)
- without doing *anything* with apache
- works with SuExec so it runs as the user so the permissions can be
700 and config files 600 - try that with PHP without days of fiddling
and breaking stuff and finally giving up ;)
Now you have the only benefit of PHP (but better) without *any* of its
downside.
I'm guessing this part, but I think you think alike and that's the
reason
you're still on this list and trying to make a point out of your bad
experiences with PHP. We can still hope that this problems will be
solved
It won't, for backwards compatibility they'll have to keep the cobbled
up mess. Or else make it new from scratch and remove the crap, but in
that case itd be a brand new langauge and would have all the problems
inherent with that :)
I think they have proved they don't care too much about backward
compatibility. You have just to see what happened to the [] and {} string
operator: deprecated, undeprecated and so on. They only care about keeping
the core features of PHP (those that really made the language stand where it
is).
Thanks for sharing your opinion and concerns, I really appreciate them.
My pleasure, I've been managing hundreds of servers for nearly a decade
and PHP has always had seriouse drawbacks. I've really honestly tried to
make a go of it but its just to much overhead to be worth it, IMHO :)
PHP doesn't have too much overhead when it's used in its most primitive way.
Everything procedural, everything on arrays and only load what you need.
This way it can run as fast as anyone. But this can only be used for small
solutions and some medium web solutions, it isn't applyable to every need.
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] preg_replace help!
2006/5/3, Nathan Heaps [EMAIL PROTECTED]: Ok, scratch that, new problem. what can I replace (.*?) with in order for php to recognise a multi-line quote/bold/italic/code/whatever? By default the . pattern matches anything except a line break you can either use ((?:.|\n)*) or add a modifier to the regular expression that changes the behaviour of the . pattern. Modifiers are appended at the end of the regular expression, after the closing delimiter: /\[i:(.*?)\](.*?)\[\/i:(.*?)\]/s The s modifier tells the regular expression to captura any character with an . pattern. With only this you should be able to captura multiline tags. Also you should consider using the U modifier which makes all repetition patters (*,+) ungreedy. This way you can avoid using the ? after
Re: [PHP-DB] preg_replace help!
2006/5/4, Martin Alterisio [EMAIL PROTECTED]: 2006/5/3, Nathan Heaps [EMAIL PROTECTED]: Ok, scratch that, new problem. what can I replace (.*?) with in order for php to recognise a multi-line quote/bold/italic/code/whatever? By default the . pattern matches anything except a line break you can either use ((?:.|\n)*) or add a modifier to the regular expression that changes the behaviour of the . pattern. Modifiers are appended at the end of the regular expression, after the closing delimiter: /\[i:(.*?)\](.*?)\[\/i:(.*?)\]/s The s modifier tells the regular expression to captura any character with an . pattern. With only this you should be able to captura multiline tags. Also you should consider using the U modifier which makes all repetition patters (*,+) ungreedy. This way you can avoid using the ? after Sorry, las message wasn't send properly (gmail isn't working right anymore for me). The last part was cutoff, it said: Also you should consider using the U modifier which makes all repetition patters (*,+) ungreedy. This way you can avoid using the ? after all repeated patterns: /\[i:(.*)\](.*)\[\/i:(.*)\]/sU
Re: [PHP-DB] Bad picture colors
2006/4/27, nikos [EMAIL PROTECTED]:
Hello list
I use the following code to shrink some photos.
$directory='/var/www/html/offroads/tmp/';
$dir=opendir($directory);
while($file=readdir($dir)) {
$dirfile=$directory.$file;
if(is_file($dirfile)) {
copy($dirfile,$directory.sm/sm_.$file);
$imgReal = ImageCreateFromJPEG($dirfile);
$x = ImagesX($imgReal);
$y = ImagesY($imgReal);
$newX=$x*0.1783;
$newY=$y*0.1783;
$img = ImageCreate($newX,$newY);
ImageCopyResized($img, $imgReal, 0, 0, 0, 0,
$newX,
$newY, $x, $y);
//$newimg=imagecolorstotal($img);
ImageJPEG($img,$directory.sm/sm_.$file);
clearstatcache();
}
}
closedir($dir);
My problem is that the color results are very bad. How can I take picture
with good colors?
Thank you
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Try using imagecopyresampled() instead of imagecopyresized(). It uses a more
precise algorithm which means: more time to complete. But since it seems
you're creating a cache of resized images that won't mather once the resize
its done.
Re: [PHP-DB] Single quotes in INSERT statements?
2006/4/26, [EMAIL PROTECTED] [EMAIL PROTECTED]: Skip Evans wrote: Hello all, I'm brand spanking new to the list and have a quick question. I was under the impression that addslashes() would handle single quote marks in INSERT statements, but when I execute the following: $sql=UPDATE images SET orderno=$orderno, url='.addslashes($url).', banner=$banner,caption='.addslashes($caption).' WHERE imageID=$imageID; ...and $caption contains something like: Don't look ...the data is chopped off at the single quote mark. How, if not addslashes(), does one handle this? No, neither mysql_escape_string or mysql_real_escape_string worked. Yes, I am using MySQL, should have said that, sorry. But anyway, even with both of these functions, the data in the string containing the single quote as in Don't Look is still being truncated at the single quote mark. Any other suggestions would be greatly appreciated. Skip For the archives: Subject of this thread is misleading since the problem was not one of an INSERT failing but of HTML not displaying properly because of quotes or other special characters in the text in the database. Just goes to show that the best way to get the right answer is to analyze the problem accurately and ask the right question. David Well, 80% of solving a problem is finding out what the problem is. If you ask them to solve that 80% on their own then asking for help is rather pointless. Anyway I agree that the subject was misleading, but this was caused by how he explained the problem, particularly on the assumption that addslashes was not doing what it was supposed to do so. What I advise is to avoid assumptions and just present the symptoms of the problem.
Re: [PHP-DB] Single quotes in INSERT statements?
1) Check that the string is not being truncated because of the column length 2) If you're seeing this data being truncated in the html output of your site, check if it isn't being caused by outputing the data without properly encoding special html characters. 3) . dunno 2006/4/25, Skip Evans [EMAIL PROTECTED]: Hello all, I'm brand spanking new to the list and have a quick question. I was under the impression that addslashes() would handle single quote marks in INSERT statements, but when I execute the following: $sql=UPDATE images SET orderno=$orderno, url='.addslashes($url).', banner=$banner,caption='.addslashes($caption).' WHERE imageID=$imageID; ...and $caption contains something like: Don't look ...the data is chopped off at the single quote mark. How, if not addslashes(), does one handle this? Thanks! -- Skip Evans Big Sky Penguin, LLC 61 W Broadway Butte, Montana 59701 406-782-2240 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Single quotes in INSERT statements?
2006/4/25, Skip Evans [EMAIL PROTECTED]: Martin Alterisio wrote: 1) Check that the string is not being truncated because of the column length This was not it. I was sure it wasn't but the first rule of debugging says never discard a possible cause, no mather how dumb it may seem 2) If you're seeing this data being truncated in the html output of your site, check if it isn't being caused by outputing the data without properly encoding special html characters. Yup! This was it. The data was fine in the database, so I wrapped the output with htmlentities() and all came out good. Thanks to Martin and all who made suggestions. You're welcome. 3) . dunno See number 2 ;) Thanks again! -- Skip Evans Big Sky Penguin, LLC 61 W Broadway Butte, Montana 59701 406-782-2240
