Australia Post Module problem - "unknown column p.products_height"

[RodG]

G'day you theslydog,

> I think you will find this is a conflict between the 2 Australian post modules.

I think you should read the thread a little more closely. The original thread/problem did relate to the Austpost module, however this was quickly resolved.
The 'extended' discussion (not yet resolved) relates to a different problem in a different module. It has nothing to do with the Aust Post modules.

There is, was, and never has been any conflict between the two different austpost modules. They will quite happly co-exist alongside of each other.

> If you installed the earlier module 'Australia Post Module' and loaded some
> products and then switched to the 'AustPost improved' you will get these
> errors.

No you will not.

> You will need to turn back on the 'Australia Post Module' to view
> these products.

Both modules happily coexist with each other.

> Don't really know another fix at this stage.

There is nothing to fix.

Rgds
RodG (author Austpost Improved).

[theslydog]

RodG writes:

G'day you theslydog,

> I think you will find this is a conflict between the 2 Australian post modules.

I think you should read the thread a little more closely. The original thread/problem did relate to the Austpost module, however this was quickly resolved.
The 'extended' discussion (not yet resolved) relates to a different problem in a different module. It has nothing to do with the Aust Post modules.

There is, was, and never has been any conflict between the two different austpost modules. They will quite happly co-exist alongside of each other.

> If you installed the earlier module 'Australia Post Module' and loaded some
> products and then switched to the 'AustPost improved' you will get these
> errors.

No you will not.

> You will need to turn back on the 'Australia Post Module' to view
> these products.

Both modules happily coexist with each other.

> Don't really know another fix at this stage.

There is nothing to fix.

Rgds
RodG (author Austpost Improved).

Maybe not for u but for me yes.

I have both modules installed but if I uninstall the 'Australia Post Module' I get the error.

1054 Unknown column 'p.products_height' in 'field list'
in:
blah blah etc etc

Reinstall the 'Australia Post Module' and the error gone.

So I leave it installed with all the shipping options unchecked and 'bob's your uncle' all is well.

tsd

[RodG]

G'day again theslydog,

> I have both modules installed but if I uninstall the 'Australia Post Module'
> I get the error.

Impossible!!

> 1054 Unknown column 'p.products_height' in 'field list'
> in: blah blah etc etc

You have this ######-backwards. The original austpost module doesn't add or use the dimension fields in any shape or form. It is the Austpost improved module that updates the database with these definitions.

> Reinstall the 'Australia Post Module' and the error gone.

The error you are describing will only occur if you install the ADMIN related php files of the AustPost_improved module but NEGLECT to update the SQL database.

The error will NOT occur no matter how many times you install or uninstall the original AustPost module.

The error will NOT occur if no matter how many time you install oe uninstall the the AustPost Improved module

It will ONLY occur if you have used the updated admin files without updating the database. (I've repeated this because it is important to know).

If YOU have somehow managed to find different then I can only assume that your memory of the events of your problem had left you somewhat bamboozled.
I'll wager anything you like that what I say is correct.

Incidently, in case you didn't pick on my comment about the original thread being resolved, and the current thread is a totally different problem with a totally different module (which I'm sure you ignored), you should take note that the AustPost improved module does create/use the p.products_height field as per "1054 Unknown column 'p.products_height' in 'field list'" HOWEVER, the error
"1054 Unknown column 'pov.products_options_values_quantity'", etc (Romys problem, and the one you responded to) has NOTHING to do with either of the AustPost modules.

You are now the second person in this thread, and one of several others in other threads that has incorrectly led romy down the wrong path by somehow assuming the 'pov.something" is somehow related to "p.something".

Bad advice is worse than no advice at all!!

Rgds
Rod

ps. I'm not trying to "have a go" at you, and I really don't mean to criticise, but unless me (or someone else) takes the time to detail the error of your ways you are quite like to repeat the same mistake again.

[theslydog]

RodG writes:
ps. I'm not trying to "have a go" at you, and I really don't mean to criticise, but unless me (or someone else) takes the time to detail the error of your ways you are quite like to repeat the same mistake again.

Yeah, relax or u will give yourself an ulcer.

I went and rechecked and the database I was using was a patched one from a 1.3.5 install patched to 1.3.7 and did not have the sql update and now seems to be ok. I deleted the original 1.3.7 default db and was given the 1.3.5 db to install but did not know what had been updated and what had not in the 1.3.5 db.

So u need to be careful with db's and patches.

tsd

[RodG]

G'day Again theslyone,

> I went and rechecked and the database I was using was a patched
> one from a 1.3.5 install patched to 1.3.7 and did not have the sql
> update and now seems to be ok.

Totally irrelevent. Not even the very latest zencart patches perform the SQL update required by the AustPost module.

> I deleted the original 1.3.7 default db and was given the 1.3.5 db to
> install but did not know what had been updated and what had not in
> the 1.3.5 db.

Again, the zencart default DB's (any version) will not upgrade the tables required for the Austpost module. These SQL updates are performed by the austpost module itself during the installation process.

> So u need to be careful with db's and patches.

Thanks for the advise, but I'm hardly the one that needs it. After all I did write the module and develop the code to perform the DB updates, so I think I have a bit of an idea as to what I'm doing. :-)

Cheers
Rod

[theslydog]

RodG your are too quick to jump to conclusions and you are not reading what I was inferring.

What I meant was the 1.3.5 db had not had any post modules installed hence no post sql patch had been run even thought the post files were in the 1.3.7 install. Ie a new install was done all patched with modules etc. Then the db was dumped for a db that came from a 1.3.5 install (it hand all the client info) and that db had different modules installed & settings etc.

The comment about db's and patches was meaning me to be careful when mix matching installs with databases from elsewhere.

so I think I have a bit of an idea as to what I'm doing

You probably do and I don't think any where in the post I suggested differently.

[RodG]

Theslydog,
We're gunna have to stop meeting like this. ;-)

> RodG your are too quick to jump to conclusions and you are
> not reading what I was inferring.

On the contrary, I know exactly what you were 'inferring', because you even repeared you error in this latest reply.

> What I meant was the 1.3.5 db had not had any post modules installed
> hence no post sql patch had been run

And my point is, there is no post SQL patch available (or required) for the austpost module and the 1.3.5db.

The original austpost module doesn't even require patches or updates for the 1.3.7db.

The Austpost Improved module (which didn't exist until 1.3.7) DOES require a DB update BUT ONLY IF YOU REPLACE THE ORIGINAL php files in Admin. (Even this isn't quite true, because the AustPost (improved) module will automatically update the database upon installation of the module. In short, when it comes to the AustPost Improved module the end user doesn't have to concern themselves with any SQL patches or updates.

> even thought the post files were in the 1.3.7 install. Ie a new install
> was done all patched with modules etc. Then the db was dumped
> for a db that came from a 1.3.5 install (it hand all the client info)
> and that db had different modules installed & settings etc.

As I said above, neither of the austpost modules require the end user to apply any SQL updates or any other patches (also not quite true, both modules require the geozones tables to be added, but this is a totally different issue than the one being discussed, namely, the 'problem' signified by the
"1054 Unknown column 'p.products_height' in 'field list' " error.

As I've been saying all along, this is NOT caused by any conflict between the two different AustPost modules (as per your original input), NOR is it caused by a failure to install or apply any SQL patches or updates, as per your latest inputs.

What it IS caused by (and the ONLY reason it will ever occur) is when people replace the files in the /admin directory from the Austpost Improved zip file, but fail to install the AustPost Module itself.

What happens then is that the /admin/ files try to reference records (not tables) that don't exist (yet). Simply completing the AustPost Improved module installion will automatically create these missing fields, and they remain there even when the module is uninstalled - and THAT means both the original AND the updated files in /admin will both work without error.

The mere fact that you are even mentioning the 1.3.5 databases in this discussion tells me that you really don't have much of an idea as to how php files and SQL updates relate to each other, especially in regards to the AustPost modules.

Cheers
Rod

[theslydog]

The mere fact that you are even mentioning the 1.3.5 databases in this discussion tells me that you really don't have much of an idea as to how php files and SQL updates relate to each other, especially in regards to the AustPost modules.

There is no need to get nasty. Everyone is ignorant - only in different areas...

also not quite true, both modules require the geozones tables to be added

I will call it sql script if it keeps you happy.


On another issue, but still with post modules. I noticed that with both installed the State/Province: drop down box is gone. If you feel the urge to post a reply (minus the ranting) that would be great.

Regards
tsd

[RodG]

> There is no need to get nasty. Everyone is ignorant -
> only in different areas...

You are confusing frustration with nasty.

> I will call it sql script if it keeps you happy.

It is not a matter of terminology, and if you think it is then you still don't get it.

It seems to me that you would rather argue than learn. :-(

I don't play that game.

> On another issue, but still with post modules. I noticed that
> with both installed the State/Province: drop down box is gone.
> If you feel the urge to post a reply (minus the ranting) that
> would be great.

Guess who didn't read the installation doc file - That's right, it was you!

Take a look, it is only 34 lines long, and your question is covered in the last few lines.

I suggest you read some of the other .txt files I wrote too, you may actually learn something more without wasting my time.

Rod

[theslydog]

...without wasting my time.

You time would probably be better spent doing some relaxation or getting out more...