[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Несколько подключений к СУБД mysql
NierRa
Предположим есть следующий код...

function connect_main() {
$auto_main = mysql_connect(HOST, LOGIN, PASS) or die(mysql_error());
mysql_select_db (DB_MAIN, $auto_main);
mysql_set_charset('utf8');

}

function connect_character() {
$auto_characters = mysql_connect(HOST, LOGIN, PASS) or die(mysql_error());
mysql_select_db (DB_CHARACTERS, $auto_characters);
mysql_set_charset('utf8');
}


И еще вот такой код...

call_user_func('connect_main');
$query_1 = ...;
$query_2 = ...;

call_user_func('connect_character');
$query_3 = ...;
$query_4 = ...;


Собственно вопрос, после открытия соединения $auto_character что происходит? Подключение $auto_main остается открытым и доступным или автоматически закрывается?
Если можно, обьясните почему так происходит?
Тест показывается, что

call_user_func('connect_main');
$query_1 = ...;
$query_2 = ...;

call_user_func('connect_character');
$query_3 = ...;
$query_4 = ...;
[
b]$query_1 = ...;[/b]


выделенное жирным выдает ошибку.

Обьясните пожалуйста как правильно работать с несколькими соединениями с базой данных в примере.

Второй вопрос - почему var_dump($auto_main) за пределами функции connect_main выдает NULL, если переменная определена. В пределах этой функции показывает resource(3) of type (mysql link)



Спустя 19 минут, 45 секунд (26.08.2012 - 16:41) KOPOJI написал(а):
Цитата
Собственно вопрос, после открытия соединения $auto_character что происходит? Подключение $auto_main остается открытым и доступным или автоматически закрывается?

остается активным, в памяти хранится. поэтому лучше так не делать (не пойму, в каких ситуациях это вообще может пригодиться? для разных юзеров что ли? а что им одновременно делать на одном скрипте на одной стороне?)
И зачем вы используете call_user_func() я тоже не понял..

По поводу второго вопроса - а вы как хотели? у вас она инициализируется именно ВНУТРИ функции, считайте функцию как миникапсулу с данными внутри (прям почти инкапсуляция biggrin.gif )


Спустя 12 минут, 34 секунды (26.08.2012 - 16:54) NierRa написал(а):
call_user_func я использую для простоты восприятия кода. Мне так проще и нагляднее. Нигде не вычитал, чтобы это влияло на производительность, поэтому и решил писать в таком стиле.

Цитата
не пойму, в каких ситуациях это вообще может пригодиться?

Есть несколько баз данных. На отдельно взятой странице нужно выводить данные с этих самых разных БД. (Даже если это глупо звучит, давайте абстрагируемся и представим, что это задано условием некой задачи)


Цитата
остается активным, в памяти хранится. поэтому лучше так не делать

Тогда почему в моем последнем примере (последние строчки кода) не работает запрос к БД connect_main если подключение активно? Есть смысл закрывать соединение через mysql_close? Как вообще правильно поступать в таких ситуациях?


Цитата
По поводу второго вопроса - а вы как хотели? у вас она инициализируется именно ВНУТРИ функции

Return ничего не меняет

Спустя 26 минут, 23 секунды (26.08.2012 - 17:20) KOPOJI написал(а):
а вы пропишите к ним
or die(mysql_error())
и увидите :) база то у вас выбирается только одна ;) он будет искать в последней базе с которой работал эти таблицы.

Спустя 5 минут, 29 секунд (26.08.2012 - 17:26) KOPOJI написал(а):
Цитата
Return ничего не меняет
а как вы это пробуете? я вот, например, наоборот уверен что меняет..
function foo() {
$arr = array('lol','foo','bar');
return $arr;
}
//вот это неверно:
foo();
var_dump($arr); //NULL
//надо вот так:

var_dump(foo()); //выведет массив

Спустя 12 минут, 50 секунд (26.08.2012 - 17:39) NierRa написал(а):
Когда добавляю return к функции - var_dump должен измениться на resource(3) of type (mysql link) вместо NULL верно?

Upd. Да, верно - с использованием return, var_dump(samefunc()) выводит resource(3) of type (mysql link)


_____________
Задача на корректную обработку данных (мое решение)
http://eu.battle.net/sc2/ru/profile/2212951/1/IIIIIIIIIIII/
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.