I have been reluctant to post this since I have so much not being consistent with other posters.

Problems faced already:
my Fnisrets/Paragon provider didn't like being queried for fields which didn't exist in a class, in pirets connect.inc at the function pirets_query_search:

$rez = db_query('SELECT system_name as system_name FROM pirets_fields WHERE classes like \'%'.$class.'%\' ');
$classy_fields = array();
while ($field = db_fetch_object($rez)) {
  $classy_fields[] =  $field->system_name;
}
$result = _pirets_query("?SearchType=Property&Format=COMPACT&QueryType=DMQL2&Limit={$limit}&Offset={$offset}&Class={$class}&Query=(" . implode('),(', $query) . ')&Select=' . implode(',', $classy_fields), 'search');

Also:
postgresql also wasnt liking any of the "$" db_query situations and probably didn't appreciate being queried without "AS" clauses either, yet, on raw querys, and some replacement of " with \', it contains all the 'correct' info. I say this because raw queries which I have harvested from Devel and Views modules such as

SELECT node.nid AS nid,
   node_data_pirets_L_ZipCode.pirets_L_ZipCode_value AS node_data_pirets_L_ZipCode_pirets_L_ZipCode_value,
   node.type AS node_type,
   node.vid AS node_vid,
   node_data_pirets_L_ZipCode.pirets_L_ListingID_value AS node_data_pirets_L_ZipCode_pirets_L_ListingID_value,
   node_data_pirets_L_ZipCode.pirets_L_Address_value AS node_data_pirets_L_ZipCode_pirets_L_Address_value,
   node.title AS node_title,
   node_data_pirets_L_UpdateDate.pirets_L_UpdateDate_value AS node_data_pirets_L_UpdateDate_pirets_L_UpdateDate_value
 FROM node node
 LEFT JOIN content_type_pirets_prop node_data_pirets_L_ZipCode ON node.vid = node_data_pirets_L_ZipCode.vid
 LEFT JOIN content_type_pirets_prop node_data_pirets_L_UpdateDate ON node.vid = node_data_pirets_L_UpdateDate.vid
 WHERE node.type in ('pirets_prop')
   ORDER BY node_data_pirets_L_UpdateDate_pirets_L_UpdateDate_value DESC
;

are returning all the correct data in a psql terminal like this:

 2675 | 80230-                                            | pirets_prop |     2675 |                                               26876 | 402 N 7th                                         | 26876                                                    1301436240

THE PROBLEM:
On default drupal node view, and in views module, only images, crc32 and property class are actually displayed, despite the other fields being populated in the db.

I think when drupal reads the fields, it is taking the wrong info? Interpreting it as bad info?
Can someone suggest something in code for me to look at? I just need a little hint, :)
Could this be related to the substr() on some php version issue? I'm on php 5.3.3. Just an idea.
And a plea for help, ty much !

Comments

rhoyerboat’s picture

hmm, hints of corruption
from psql \dt, the first content_pirets_* occurence

public | content_pirets__spacerentalinclusions_22 | table | drupal6
                                ^duplicate underscore
rhoyerboat’s picture

Title: db 'correctly' populated, drupal fetching only a few fields » db 'correctly' populated, drupal fetching only a few fields
Status: Active » Postponed

I tried the beta6 version in postgresql, now I am trying, beta6 in mysql, then dev3.x.3.x in mysql and if that doesn't work, then Ill downgrade php to the latest even numbered release, and if that doesn't work, back to postgres/3.3 php/pirets-3.x.3.x-dev ..

Its just that, on pirets.info, Paragon 1.0 is listed as "OK," so it must be my weird LAMP..
really, I think code-wise, pirets/postsql/my paragon provider's responses put good data in places where drupal doesn't know to look, what I cant figure out is where the views module generates a great manual query, but doesn't use the data that query recalls when its time to theme the site.. to me, just baffling, Need more CCK skill I guess. And to get in the habit of installing DBG on these things.

rhoyerboat’s picture

Title: db 'correctly' populated, drupal fetching only a few fields » (postgresql support) db correctly populated, what to make it visible?

Okay, so yeah, the mysql switch worked for me, so my site will be moving to production and there will forever be a hole in my life where I could have made it work in postgresql..

posted for posterity,Thanks for PIRETS!,(almost)always a happy contributor,love,
rhoyerboat