Site Links
Home
Features
Documentation
Pricing & Order
Members Area
Support Options
UBBDev.com
UBBWiki.com
Who's Online Now
3 registered members (M4TT, isaac, Morgan), 58 guests, and 401 spiders.
Key: Admin, Global Mod, Mod
Member Spotlight
M4TT
M4TT
Canada, SK
Posts: 51
Joined: March 2015
Show All Member Profiles 
Top Posters(30 Days)
Gizmo 12
M4TT 9
Ruben 8
isaac 5
mmkk 4
FREAK 3
Latest Photos
Chinese Buddhist temple.
My buddha beads.
Rendered Walls
Multi-Screen wallpaper
Stockholm Metro
Previous Thread
Next Thread
Print Thread
A head scratcher regarding evaluation of field contents. #184445
05/18/07 06:46 PM
05/18/07 06:46 PM
Joined: May 2007
Posts: 17
B
bilbo Offline OP
stranger
bilbo  Offline OP
stranger
B
Joined: May 2007
Posts: 17
I'm not sure if this is a bug, or pilot error, but here it goes:

I fear I知 a little bit unfamiliar with the technically correct vernacular, so I知 going to use an almost identical analogy that I have personally experienced with Microsoft Excel.

Often, for long and or complicated or repeated formulas, I like to use the 田oncatenate function in Excel, but there is an odd twist with that function when building macro code or formulas.
Of course Excel will not 途ead a concatenated result until you first perform a Copy>Paste Special>Paste Values.
However, an extra little twist is that Excel will not 都ee the pasted values as actual code or formulas either because the initial format is as 鍍ext.
In other words, the formula just sits there, and is NOT evaluated.
However, Excel being what it is, I have discovered if I merely 田lick inside the cell, and hit [enter], Excel re-evaluates the 鍍ype, 都ees the formula, changes the cell type, and calculates the formula.
Another way I have discovered to force Excel to perform a bulk re-evaluation of the cell type is to perform a 典ext to columns step on single columns of pasted concatenated formulas being careful to select a delimiter that is not included in any of the formulas. Again, Excel examines each cell for the type of data contained in it, 都ees formulas, changes the cell types and evaluates the formulas.

OK, now that the analogy is explained, here is what痴 happening to me that is REMARKABLY similar (if not identical) in a MySQL database.

We池e running UBB Threads version 6.5
In our forums, users are only allowed to use 杜arkup and can make links and post images and change font colors, and that is about it.

As an administrator in the forums, I have two ways of editing posts.
Firstly, to 兎dit posts from within the 渡ormal forum view.
You get a fairly standard 菟ost screen and perform any edits you wish. In this screen you see ALL of the actual code for the post, including the markup code if any.
HOWEVER, the catch is that when you edit a post via this means, the forum software adds an extra comment at the bottom of the post indicating it was edited, by whom and when it was edited.
Secondly, is to open the main 田ontrol panel by a manual SQL Command.
Having tested a few things here, there does not appear to be anything I can稚 do here using standard MySQL query syntax.
Including editing posts WITHOUT leaving the 兎dited by signature as happens when I use the first method above.

If I perform a query to look at a specific post in the SQL command screen that INCLUDES any markup commands, what I actually see is the markup EVALUATED result, NOT the actual base content. For example, if a post has this actually visible:
撤lease see the picture here (where the word 塗ere is actually a link, then I know that the actual content of the cell has to be 撤lease see the picture path/here
However, again, all I can see in the SQL Command screen is the evaluated result, not the actual content.

So we have a situation where we have changed a page on the main site and not in the forums, and it actually has a new URL to the page.
There are several links throughout the forums to the ORIGINAL page that I want to update to the new path, but I would prefer to not leave the 兎dited by signature in each post by performing the edits manually.
Using the SQL command screen, I can easily find each of the posts that contain the link by using the InStr function.

Now here is where things start getting like the Excel analogy.
As a test similar to this example (referencing the same above example):
UPDATE w3t_Posts SET w3t_Posts.B_Body = "Please see the picture path/there"
WHERE (((w3t_Posts.B_Number)=3300));

The SQL command screen correctly told me that 1 record was effected.

HOWEVER, when I view the post in either the forum, or via the SQL COMMAND, it is no longer evaluating the markup!!!
All the code is there, exactly as it should be, but it is not being evaluated.
And here is where it gets EXACTLY LIKE THE EXCEL ANALOGY.
If I go to the regular Forum view, and go to edit the post (as described in the first option above), THE MARKUP is perfectly and correctly evaluated without me having to change a thing!!!
Just like what happens in Excel by clicking in a cell and hitting enter with concatenated formulas.
The problem is that if I 堵o back it does not save that view, and it remains the 砥n-evaluated version.
So I end up back at square one having to manually edit each of the posts and leaving the edited by signature.

Before you suggest it, yes, I already guessed that I could edit the tables to remove the flag for 兎dited by, I would miss this chance to try and understand what is physically happening here.

Now where things are different between Excel and MySQL is that Excel evaluates cell types on the fly, by itself, every time you hit 兎nter. Sure you can 吐orce a cell type to be one thing, but it actually ALWAYS re-evaluates your forced type anyway (except when you force the type to be plain text).
HOWEVER, with databases, MySQL being no exception, there is no cell types. Data are forced to certain data types by the column format, and not by the cell at all.

So, can anybody help me understand what is happening here?
Is there an SQL function that will force the contents to be evaluated?

Sorry for the long winded explanation, but when I致e discussed this with others they get a blank look and I end up giving the excel analogy anyway, so I thought I壇 just get it all out in one shot.

Thanks in advance for any help or explanations.

Last edited by bilbo; 05/18/07 06:47 PM.
Re: A head scratcher regarding evaluation of field contents. [Re: bilbo] #185442
06/01/07 11:12 AM
06/01/07 11:12 AM
Joined: Aug 2006
Posts: 1,530
Breda, NL
Yarp邃「 Offline
veteran
Yarp邃「  Offline
veteran
Joined: Aug 2006
Posts: 1,530
Breda, NL
UBB6 does not store the markup code.

When you enter a post, it goes through the markup proces, where all UBB is translated to the corresponding HTML.

It only goes through this proces if you post it.

When you edit a post, the HTML is translated back to UBB code.

So there is no way you can add UBB code to a post by editting the table directly. It has to go through some translation/processing code to proces that markup code.


[Linked Image]
Re: A head scratcher regarding evaluation of field contents. [Re: Yarp邃「] #185799
06/06/07 06:43 AM
06/06/07 06:43 AM
Joined: May 2007
Posts: 17
B
bilbo Offline OP
stranger
bilbo  Offline OP
stranger
B
Joined: May 2007
Posts: 17
Hmmm, so the mistake is to edit the post using the markup code?

If I' going to edit the post via editing the table directly, I should just edit them with html!

Assuming I use the same format of HTML that the UBB converts the mark up back and forth, then if I went to edit the post via the normal means, it should still translate the html to mark up.

Ding! That had no occured to me.

THANKS!!!


Shout Box
Today's Birthdays
No Birthdays
Recent Topics
Users Unable to Upload Avatar [Not a Bug]
by M4TT. 12/13/17 08:51 AM
Shout Box Sound Effect
by M4TT. 11/29/17 08:28 PM
Ad island
by TGCsanderson. 11/25/17 06:41 PM
Taking to long to connect to DB
by AstroCat. 11/24/17 12:34 PM
Forum Statistics
Forums36
Topics35,015
Posts190,545
Members12,046
Most Online978
Jun 24th, 2007
Random Image
Powered by UBB.threads™ PHP Forum Software 7.6.1
(Snapshot build 20171217)