Setting total db size to a variable.

I have a question in regards to finding the total db size and setting it to a variable.

How would I go about this?

Hello,

This is a reply to an e-mail that you wrote on Sun, 20 Jul 2003 at
00:42, lines prefixed by '>' were originally written by you.
> I have a question in regards to finding the total db size and
setting
> it to a variable.
> How would I go about this?

For mysql this will do the trick...

$info = mysql_fetch_array(mysql_query("show table status from
$databasename = '$tablename'"));
$sizeinMB = $info["Data_length"]/1024/1024;

--
phpmachine :: The quick and easy to use service providing you with
professionally developed PHP scripts :: http://www.phpmachine.com/

Professional Web Development by David Nicholson
http://www.djnicholson.com/

QuizSender.com - How well do your friends actually know you?
http://www.quizsender.com/
(developed entirely in PHP)

* Thus wrote Jason Martyn (in3words@telus.net):
> I have a question in regards to finding the total db size and setting it to a variable.
>
> How would I go about this?

http://www.mysql.com/doc/en/SHOW_TABLE_STATUS.html

Curt
--
"I used to think I was indecisive, but now I'm not so sure."

* Thus wrote John Manko (xerid@adelphia.net):
> I'm having a little trouble understanding how to accomplish this.
> Should the entire browsing session be HTTPS after login, or just for
> important functions like "login" and "checkout"
> If noly for those function, who should I design to jump back an forth.
> I know DB should be used for cart items, but when I jump to HTTPS,
> should I enclude the session ID (which will be stored in the DB) as a
> GET query string field? If not, how else will I be able to know which
> user to continue with. I don't see any functions that will let you
> specify which session ID to continue with. What is the best practice?

It is overkill to run whole site on https, you only need it when
sensitive data is being sent back and forth (ie, credit card, login
info..)

Technically you only need to use https when the user actually
submits the form to the script that processes. So the page that
generates the form for the user to login does NOT need to be encrypted,
the forms action will contain the https url.

In general practice though I would probably encrypt the login/checkout
page just so 'joe user' feels more secure (seeing the little secure icon
in the lower left corner.)

You dont need to touch any php code, just modify the html so the
properlinks point to https where needed.

On and advanced note, there are ways to protect a users password on a
normal http connection. The authentication program I helped developed
and use has the abilty to make a hash of the password on the client side
then send the hash value to the authentication script. The authenication
script never sees the password just verifies the hash.

http://sourceforge.net/projects/diggerauth/
(only cvs version is available, you need ot browse cvs to see the code)


HTH,

Curt
--
"I used to think I was indecisive, but now I'm not so sure."

On Monday 21 July 2003 00:30, Curt Zirzow wrote:
> I'm curious as to why your email has these headers:
>
> References: <006801c34e57$96cf5fc0$858fb8a1@d>
> <20030720000349.GD39781@bagend.shire> <032701c348dd$618d2c40$840169c8@Juan>
> In-Reply-To: <032701c348dd$618d2c40$840169c8@Juan>
>
> My email program thinks your discussing db sized and how you can get it
> into a variable in php.

That's because:

---------------
You have started a new thread by taking an existing posting and replying to
it while you changed the subject.

That is bad, because it breaks threading. Whenever you reply to a message,
your mail client generates a "References:" header that tells all recipients
which posting(s) your posting refers to. A mail client uses this information
to build a threaded view ("tree view") of the postings.

With your posting style you successfully torpedoed this useful feature; your
posting shows up within an existing thread it has nothing to do with.

Always do a fresh post when you want to start a new thread. To achieve this,
click on "New message" instead of "Reply" within your mail client, and enter
the list address as the recipient. You can save the list address in your
address book for convenience.
---------------

In the above, $you =='john'.

--
Jason Wong -> Gremlins Associates -> www.gremlins.biz
Open Source Software Systems Integrators
* Web Design & Hosting * Internet & Intranet Applications Development *
------------------------------------------
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
------------------------------------------
/*
30. Ooops. Save your work, everyone. FAST!

--Top 100 things you don't want the sysadmin to say
*/

Curt Zirzow wrote:

> On and advanced note, there are ways to protect a users password on a
> normal http connection. The authentication program I helped developed
> and use has the abilty to make a hash of the password on the client side
> then send the hash value to the authentication script. The authenication
> script never sees the password just verifies the hash.

So, I can't sniff the password, but I can sniff the hash and then send
the same one when I want access. This doesn't protect much until the
user changes their password and I have to get their new hash.

--
---John Holmes...

Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

PHP|Architect: A magazine for PHP Professionals – www.phparch.com

John Manko wrote:

>>
>>
>> You dont need to touch any php code, just modify the html so the
>> properlinks point to https where needed.
>>
>>
> I tried that. However, the session is different when going from 80 to 443.

You'll have to pass the SID through the form or URL when switching from
HTTP to HTTPS.

--
---John Holmes...

Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/

PHP|Architect: A magazine for PHP Professionals – www.phparch.com

> if you do sniff the hash, the key, and the session. You will have to
> get your request in before the key becomes stale,

race, race!

> In most cases the authentication is the
> first thing done so we're dealing with micro seconds.

Most cases?

Why re-invent the wheel?

--
Joel Rees, programmer, Kansai Systems Group
Altech Corporation (Alpsgiken), Osaka, Japan
http://www.alpsgiken.co.jp

This is what I decided to do. So the pages that need to be secured, I
send the the SID as a GET QUERY variable.
I don't like it, but it's the only thing I seems right.

Joel Rees wrote:

>>if you do sniff the hash, the key, and the session. You will have to
>>get your request in before the key becomes stale,
>>
>>
>
>race, race!
>
>
>
>>In most cases the authentication is the
>>first thing done so we're dealing with micro seconds.
>>
>>
>
>Most cases?
>
>Why re-invent the wheel?
>
>
>