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

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).

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

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.

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. :mellow:

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

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

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 doingYou probably do and I don't think any where in the post I suggested differently.

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

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

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

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

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

I agree with you 100%, but the trouble is, experience has taught me that if I don't correct any mis-information regarding code that I've developed early in the piece, I'll end up spending far more time trying to put people straight in the longer term.

USUALLY I manage to put these initial 'fires' out in a message or two, but every so often some ignorant little twerp likes to think they know my code better than I do, or they go off on some other tangent in a lame effort to 'save face'. When this happens I generally wish I'd let the original mis-information pass without comment because such people end up using more of my time than I would spend putting out the subsequent fires.
Alas, I don't know who these people are in advance.

MODERATOR NOTE:

It's time to stop bickering. Both of you ... keep your snide comments to yourself.
This forum is not the place to harass nor repeatedly insult others or stoop to name-calling.
Continued inappropriate dialog will result in suspensions.
If you have anything unpleasant to say, log off and say it to your dog instead.

Let's keep this thread on useful technical issues.

well after days of searching for an answer on the net, i discovered this thread to read 4 pages of crap.

what should be done to stop people encountering this error is put a little message in the austpost updated file that states something like "requires aust post module to be installed first!"

or instead of releasing half a file and creating headaches for people (i'm sure i'll appreciate your work when i eventually get it working) why not put everything together and release a totally new module instead of 1/2 a module.

thanks for wasting my time.

G'day Crusty,

well after days of searching for an answer on the net, i discovered this thread to
read 4 pages of crap.

I apologise for the 4 pages of crap, but that is what happens when people jump midway into into a thread with an unrelated problem and then decides to argue their point rather than obtain a little knowledge.

So exactly what is your problem? I assume it has something to do with the Austpost module, and not some unrelated error (eg Unknown column 'pov.products_options_values_quantity' ), because as per these 4 pages of crap, this is a totally different error that has nothing to do with the AP module.

what should be done to stop people encountering this error is put a little message
in the austpost updated file that states something like "requires aust post module
to be installed first!"

Let me get this straight, you want the Australia Post shipping module to include some kind of text that says "To use this module you need to install it first"?
I kinda thought that would be a rather obvious thing to do (ie, install it, THEN use it).
I guess I'm not quite understanding what you are really suggesting?

or instead of releasing half a file and creating headaches for people why not
put everything together and release a totally new module instead of 1/2 a module.

Again, I must be misundering what you are saying. Everything IS all put together, and always has been. There has never been any kind of '1/2 a module.

The installation of the AustPost (improved) module really doesn't get any harder than extracting all the zipped files into the default locations, then logging on as 'admin', browsing to the modules/shipping area, clicking on the 'Install' option (so the previously extracted files integrates with zen-cart), and finally, selecting the shipping options you wish to offer.

The people that have been having problems with the 'unknown column p.products_height' error are those that either failed to complete the installation, or, re-installed thier zencart database while still leaving the modified AustPost files intact.
BOTH problems are easy to overcome.

thanks for wasting my time.

My pleasure.
Rod

Hi RodG

From reading these posts, I understand that I must install the module to avoid the :1054 Unknown column 'p.products_height' in 'field list'" error appearing in the Products section.

My problem is that AFTER extracting the files into their default locations (and checking to see they got to the right places) AustPost doesn't appear in the Modules-Shipping Modules list to allow me to install it.

Could you suggest what I may have done wrong, please?

Regards

Geronimo - Philip.

Hi again Rod

Some more info on my installation in case it helps.

I'm using v1.3.8a of Zen Cart and have your latest v2.1.3 of AustPost - Improved.
I've added Fual Slimbox but have it OFF right now.
I'm using the apple_zen template.

Regards again,
Geronimo - Philip

And a third "hello" Rod

I've found my problem. I dropped both "admin" and "catalogue" into the root directory when I should have left out the "catalogue" directory level and put "includes" into the root.

That's THREE messages you can ignore now :). I have a couple of other issues but I KNOW they've been answered elsewhere so I'm off to look now.

Kind regards

Geronimo - Philip

Geronimo:

And a third "hello" Rod

I've found my problem. I dropped both "admin" and "catalogue" into the root directory when I should have left out the "catalogue" directory level and put "includes" into the root.

That's THREE messages you can ignore now :). I have a couple of other issues but I KNOW they've been answered elsewhere so I'm off to look now.

Kind regards

Geronimo - Philip

Thanks for letting me you solved the problem. Not all are as considerate.

Cheers
Rod

Hi all, thanks for the brutal discussion, we're all passionate about our carts!

I just want to report that I followed theslydog's idea, turned on AustPost, deselected all the options to effectively offline it while it was installed, and it solved my 1054 Unknown column 'p.products_height' error - I don't have time right now to set up a clean install on this busy shop, but I also appreciate RodG's details and work on the module, so am looking forward to that time when my universe is in order to get a nice clean install happening to take advantage of the updates - but for now, the workaround is making me happy!

Further to the above, I have noted that now turning the AustPost module off after turning it back on to resolve this issue, the error goes away, so I'm now flying on all engines with just AustPost (improved) - happy camper!