Hi,
smf_db_drop_table() returns false - so doesn't drop the table - but I don't know why.
Is there a way to show the error?
Thanks,
Josh
Just to be sure: are you sure you need this function?
This is usually used by the package manager, so it's unlikely you have to call it yourself...
You should never be calling this directly.
Yep, I'm sure I need this function ...
- I'm writing a converter to import fusetalk categories, boards and posts to smf.
- When adding boards, I create a temp table (using smf_db_create_table()) with columns fusetalk_board_id and smf_board_id
- When inserting posts, I can then use the fusetalk_board_id to get the smf_board_id to put in the createPost()
I need to delete that table when done.
Yes, I can drop it manually, but my program should clean up after itself.
You should NEVER be calling the smf_db functions directly. Should be using $smcFunc, not that that makes an enormous difference.
You might also find it useful to use the converter code rather than writing it totally yourself...
I can use smcFunc.
Unf, no converter out there for fusetalk > smf, so gotta write it myself.
There's nothing in the documentation that says don't call directly
- http://support.simplemachines.org/function_db/index.php?action=view_function;id=607
But - back to my question ;) - is there a way to show the error that smf_db_drop_table() encountered?
I realise that, but that's specifically why I'm suggesting you use the converter base because it will help you with some of this stuff.
And I don't actually care what the function DB says, because it's mostly out of date in a variety of places and will be deprecated with 2.1 anyway. There are circumstances where your code WILL fail if you try to call the functions directly.
Show how you are using the function?
There isn't much to do with that function: just pass the name of the table you want to remove...
Lainaus käyttäjältä: jjsmith - lokakuu 16, 2013, 12:42:50 IP
Unf, no converter out there for fusetalk > smf, so gotta write it myself.
Arantor means convert.php and then write a fusetalk_to_smf.sql file instead of rely on a "custom" converter. ;)
"...converter base .." and "... Arantor means convert.php ..."
I didn't know about the converter base - convert.php - is that an smf-supplied script (like SSI.php) - is there documentation ?!?! I'd love to use something like that.
This is how I'm using ..drop_table()
global $smcFunc, $db_prefix;
$result = smf_db_drop_table("{$db_prefix}fusetalk_categories");
"... it's mostly out of date in a variety of places and will be deprecated with 2.1 anyway...."
Oh ... Bummer? The description for it says it's new/revised for 2.0 but doesn't mention being deprecated....
convert.php is the base for *all* converters, if you look in the downloads for each converter you will see convert.php which you can use as the basis for your own.
You're STILL not supposed to call it directly regardless of anything else. You are supposed to use $smcFunc which will have loaded the correct base for the DB functions and with the appropriate db_extend() call, will also load the right functions for you, then you can use $smcFunc['db_drop_table'].
The *function database* it is out of date in a variety of places. The code for 2.1 largely has not changed in that direction... except for having both MySQL and MySQLi support (which DEFINITELY means you should not be messing about trying to do it directly and should ALWAYS use the proper methods)
I see ... so i need to be writing sql, not php...?
Is there any documentation on convert.php - how to use it???
Will I have to tweak convert.php, or is it the same for all converters?
Yes, not that I remember (other than looking at the other converters), and probably not. convert.php should allow for raw PHP on the occasions you need it.
* convert.php is the same for all the converters.
* There are several versions around, if you pick the one attached here (http://www.simplemachines.org/community/index.php?topic=477019.0) there should be some of the most annoying bugs fixed (there is also this version (http://www.simplemachines.org/community/index.php?topic=512268.0) but it's kind of experimental, so dunno...).
* there is no documentation (sigh... you can pick an existing converter and see how it works...mostly)
* it's not entirely SQL, it supports adding php too and manipulate the results of the queries.
Arantor was faster. :P
ok - i'll dig into convert.php / sql....
But ... does convert.php require that the SMF forum be brand new?
See my situation is - I'm merging my fusetalk cats/boards/posts into an existing SMF forum.
Will convert.php cause any problems with the existing SMF content?
Well it is designed to be run on a fresh install, as normally things like message ids get preserved.
Doing it the way you're doing it is going to break things for sure, because SMF uses message ids to order posts - so all the imported posts from that other source are all going to be more 'recent' than whatever's in your existing forum.
Ughh ... so sounds like i'm back to plan-a....
Sorry to keep y'all so long on this ... but would you mind please reviewing the following and letting me know of any problems that stand out???
My process:
---------------------------------------
- sql extract Categories, Boards, and Posts from fusetalk to text files
- createCategory() - all the categories
- createBoard() - all the boards, putting them in their proper categories
- createPost() - all the posts, putting them in their proper boards
- all the posts will be associated with a *single* member.
(All these fusetalk boards will be read-only - they are just for reference)
- not importing any attachments
--------------------------------------
** My goal is that, because i'm using the *SMF functions* to add the cat/board/posts, I don't have to worry about clobbering all the data already there.
The code I've written for Categories is below ...
I'm using SSI.php for my environment setup and I bring in Subs-Categories.php so I can use the function
....
require_once('../SSI.php');
require_once('../Sources/Subs-Categories.php');
global $smcFunc, $db_prefix;
db_extend('packages');
....
foreach($fusetalk_cats as $category)
{
$catOptions = array('cat_name' => $category['vchcategoryname'],
'is_collapsable' => true );
createCategory($catOptions);
}
...
Thanks!
Josh
Honestly, I wouldn't try and use those functions, certainly for creating posts I *really* wouldn't because it does so much more than just adding posts (it also does queries for notifications and whatnot)
To be honest I'd just do bare inserts and be done with it.
HUH??!!! :o :o :o
Ugh.... I really do appreciate your replies, but I'm getting really frustrated here....
I'm really shocked! Doing so much more is the reason I *am* using it, and now a Team Developer is telling me not to use them?
So - can I use *any* of the functions on this page???
http://support.simplemachines.org/function_db/index.php?action=main
I'm really surprised. The API seems well documented, but you're saying it's either dangerous or soon to be deprecated.
The *last* thing I want to do is 'bare inserts'. I don't want to re-code what SMF is already doing. I want to use their API utilize what they are already doing...
:'( :'( :'(
Please stop putting words in my mouth.
It's your converter, it's not for me to tell you what you can and can't do. Simply that you *should* use $smcFunc instead of the bare database functions, and that me personally I wouldn't use the internal methods because they have unexpected side effects that may or may not affect you. Doubly so for 2.1 where there are TWO DIFFERENT BACKENDS for MySQL whose files and dependencies are managed on your behalf and you should be using the proper API ($smcFunc) for it for that reason.
For example for dependencies, createPost for example requires a minimum of 3 queries per post. One to insert the post, one to create/update the topic, frequently one to update the post with the topic id, and then one to worry about notifications.
All I said is that I personally wouldn't because if I had a structure I was working from and to, I'd do it manually and avoid the massive extra load. I could add entire topics in potentially three queries total (rather than 3-4 PER POST), which would be much faster and more efficient.
LainaaI'm really surprised. The API seems well documented, but you're saying it's either dangerous or soon to be deprecated.
That is not what I said. >:( That's twice you've ignored what I'm trying to tell you in favour of overreacting.
The 'API' as you call it (which it isn't, really, it's certainly not intended to be for those things), is stable for 2.0. It is mostly, but not totally, the same in 2.1. For 3.0 it will be totally different.
The thing I told you, and that you have misinterpreted, is that the DOCUMENTATION is going to be deprecated. 2.1 has documentation throughout the source in the form of phpDocumentor blocks and the documentation will subsequently be built from that.
Maybe you can check this
http://www.simplemachines.org/community/index.php?topic=512266.0
All queries are made with $smcFunc as it had been told here.
If you're trying to merge the topics with an existing board then the existing converters might not suit you.
For your case, you will probably have to store, temporarily, the old topic, users, etc, ids so that you can relate them with the new ones they will receive when adding them to an existing database...