Tue Dec 6, 2005 New Discussion
Posted in Computers & Tech / Databases
Author: Quatrux Total-Replies: 7
Use phpmyadmin to import export sql data ? because I think you're using the phpbb one ? just export with phpmyadmin your old database into a textfile and later improt it to the new one when you create it on your other place, use phpmyadmin and/or cpanel, cpanel can backup too.
Posted in Computers & Tech / Operating Systems / Windows (All Versions)
Author: twitch Total-Replies: 19
I think, you can cheat the system a little. If you connect a two-way USB cable from your new machine to your old one, you should be able to do it. Note that I am going on the presumption of a theory that data trasnfer comes in multiple forms.
Posted in Computers & Tech / Operating Systems / GNU/Linux
Author: docduke Total-Replies: 23
QUOTEMany face problem while transfering file from Linux to windows and Vise versa.
You need to clarify how Linux and Windows are connected. If you have a dual-boot machine and you're after files from one to the other, do it from the Linux side. Linux can read anything (unencrypted) that Windows can write. It is easiest to keep track of things if you create a separate data partition that is accessible to both operating systems. That reduces the chance that you may accidentally damage something in the Windows operating system.
The tips mentioned above are important. FAT32 has major problems with really large files. NTFS is (unfortunately ) the only way to go with big (>2GB) files in Windows. A recent version of Linux should be able to write NTFS. If not, it will probably give you a warning. If you "must" stay in FAT32, the option on the Windows side is HJ-Split. The corresponding functions on Linux are split and cat, but the command-line invocations involve dd. They are pretty arcane, and dd can do really nasty things if it is fed the wrong parameters. If you decide to stay with FAT32 and split files, you are really better off doing it in Windows.
If your Linux and Windows machines are running simultaneously on a network, your best bet is Samba. There is a learning curve, but again, most modern versions of Linux have good defaults built in. With a properly configured Samba, Linux can read and write files on the Windows machine and Windows can read and write files on the Linux machine, depending of course on the permissions both machines have set. In this case there is no concern about correctly writing NTFS files on the Windows machine, because Windows native networking commands are performing the operations.
Most of my Linux work is on openSuSE. There, if you know how to interpret and use the /etc/fstab file, then it is an easy step to using the /etc/samba/smbfstab file. It lets you define partitions on the Windows machine so that they are accessible on bootup from the Linux machine, just like any Linux file. The samba files may be elsewhere on other Linuces.
Posted in Computers & Tech / Programming / Programming General / C, C++ & Visual C++
Author: yungblood Total-Replies: 0
Ok, here's a challenge that I know is possible, but I need a little help. I think alot of people would be interested in using this, once they realize the possibilities.
First, I would like a way of getting online for *free* without doing anything illegal. I also want to be able to do so wirelessly.
Here's the solution that I came up with. I have a cell phone that is on a family-plan. All calls between me & anyone else that has my service provider is free. The phone I have doesn't have the option of using it as a modem, so I would like to use my soundcard as a modem, use the cell phone just as a way of carrying the modulated data. I've taken a cheap headset, removed the earbud/mic, and attached 2 stereo plugs. If I plug them into my soundcard, any sound played from my computer is sent through the phone to the other person. And anything they say can be recorded by my computer. So I realized that if my computer can send/recieve sound from the cell phone, it should be easy enough to do the same with data.
I know that ages ago, instead of a modem that just directly connected to the phone line, you had a box that you would place the handset of your phone on. That box would convert your data to audio, and the phone would transfer it.
I know that copying the old bbs & terminal software would probably be the easiest for transfering data, but I want to go a step further, and have it talk tcp/ip. Yes, I know that a cell phone connection would probably be slow. I'd probably be lucky to get a 2400 baud connection, but for simple stuff, it'd be all I need. Certainly all I'd need for e-mail.
My problem is this, I don't know how to write drivers for windows. I could do all the code talking to the sound card, that's easy enough. I need to know how to tell windows(95) that I have a new type of network interface. I could also use some help getting the most effecient transfer rate.
I know that this is a rather challenging problem, but I think if it can be solved, it'd make it so that alot of people could take more advantage of the free connections that cell companies offer.
Posted in Computers & Tech / Hardware Workshop
Author: manuleka Total-Replies: 20
Honestly I think it has more to do with speed and the reliability of that speed then anything else. With a plug that small it's very hard to keep from having signal bleed from one connector to the other. If/when they figure out how to over come that issue I think we will see the microUSB plug more, especially with the popularity of netbooks and tablets picking up.
Link: view Post: 172896
i agree... although with mobile devices through and tablets the small microUSB port delivers enough bandwidth to be utilized for charging/data purposes...
Posted in Computers & Tech / Networking
Author: magiccode9 Total-Replies: 11
Because I just use remote software for getting data from home pc.
And all of it was not important data.
So I use build-in netmeeting remote app for remote control only.
But you have to install the netmeeting 3.0 first on some system
such as windows NT 4.0.
Windows 2000 includes it already.
But Windows XP should be required installation.
Posted in Computers & Tech / How-To's and Tutorials / OS / Windows
Author: psychologist Total-Replies: 5
Windows 2000/XP Registry Tweaks
Windows 2000 and XP are built on NT technology and both are generally better optimized for networking than Windows 9x and even NT4. Regardless, both XP and 2000 are still configured with respect to Ethernet rather than high-speed Internet connections, where latency plays a major role in throughput. Here, you will find specific information on how to optimize the Windows 2000/XP Registry for Cable Modems, DSL, or any similar type of broadband Internet connection.
Customizing the Windows Registry assumes some proficiency in tuning Windows configuration files. If you don't feel comfortable editing it, please use our TCP Optimizer program, or the Windows 2000/XP registry patches. both those options will add all the parameters and set all the optimal values in the Registry automatically for you.
If you'd rather make the changes yourself, or prefer to experiment with different values to fine-tune your connection, follow the directions for editing the Registry below.
Editing the Windows 2000/XP Registry
To edit the Registry, you need to use an editor, such as Regedit. As with previous Windows versions, it can be accessed from the Start Menu ( START > Run > type "Regedit" ). Note that most of the values recommended on these pages are not present in the Registry by default and you might have to add them manually. Also, for most of the tweaks to take effect you must Reboot.
It is strongly recommended that you backup your Registry before editing. The easiest way to backup your Registry is from within the Registry Editor, just choose "Export Registry File" from the pull-down menu.
Recommended settings for Windows 2000 / XP
Windows 2000 & XP, unlike NT supports large windows as described in RFC1323 ( the 'RcvWindow' has a maximum value of 2**30 rather than 64K), and includes some other improvements over its predecessors you can use to speed up any transfers. The best settings are listed in red, the descriptions and other options are added to provide you with better understanding and enable you to customize your settings.
All the following entries, unless otherwise noted should be placed in the Windows 2000/XP Registry under the key
The value of TCP Window in the Windows 2000 Registry is DWORD, representing number of bytes, with range from 0 to 2^30. The recommended values (in red) optimize TCP for any high speed Internet connection and work best in most cases, however if you'd like to use a custom value follow these guidelines:
For best results, the TCPWindow should be a multiple of MSS (Maximum Segment Size). MSS is generally MTU - 40, where MTU (Maximum Transmission Unit) is the largest packet size that can be transmitted. MTU is usually 1500 (1492 for PPPoE connections). To determine the MTU value of your ISP.
There are three places in the Windows 2000 Registry where you can add the TCP Window parameter.
GlobalMaxTcpWindowSize="256960" (DWORD, number of bytes) Valid range is from MSS to 2^30. Add the value as a decimal. Note: For best results RWIN has to be a multiple of MSS lower than 65535 times a scale factor that's a power of 2, i.e. 44 x 1460 = 64240 x 2^2 = 256960. If you choose to use a RWIN lower than 65535, you can simply make it multiple of MSS and turn scaling off (Tcp1323Opts=0)
TcpWindowSize="256960" (DWORD, number of bytes) Valid range is from MSS to 2^30. Add the value as a decimal. TcpWindowSize can also exist under TcpipParametersInterface - if added at this location, it overrides the global setting for this particular . Note (10/20/00): Seems MS has found another bug in Windows 2000, the TCPWindowSize should be configured with the global setting (GlobalMaxTcpWindowsSize) rather than this one - Q263088
Note: For best results RWIN has to be a multiple of MSS lower than 65535 times a scale factor that's a power of 2, i.e. 44 x 1460 = 64240 x 2^2 = 256960. If you choose to use a RWIN lower than 65535, you can simply make it multiple of MSS and turn scaling off (Tcp1323Opts=0)
Tcp1323Opts is a necessary setting in order to enable Large TCPWindow support as described in RFC 1323. Without this parameter, the TCPWindow is limited to 64K.
Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)
Note: Tcp1323Opts="3" might help in some cases where there is increased packet loss, however generally you'll achieve better throughput with Tcp1323Opts="1", since Timestamps add 12 bytes to the header of each packet.
DefaultTTL determines the time in seconds and the number of hops a packet lives. While it does not directly affect speed, a larger value increases the amount of time it takes for a packet to be considered lost, discarded and retransmitted. A value that's too small can cause packets to distant servers not to reach their destination at all.
DefaultTTL="64" (DWORD, recommended setting is 64. Other settings that are widely used are 128 and 32)
When set to 1 (True), TCP attempts to discover MTU automatically over the path to a remote host. Setting this parameter to 0 causes MTU to default to 576 which reduces overall performance over high speed connections. Note that this setting is different than our Windows 9x recommendation.
EnablePMTUDiscovery="1" (DWORD - boolean, valid settings are 0-->False and 1-->True. Many connections perform better with this entry at 1, however, if you prefer to set your upstream to send fixed 1500 packets, you might want to use 0 instead). When set at 1, establishing connections and initial transfer speed might slow down a bit, however you will get better throughput if somewhere in the path large packets need to be fragmented.
Setting this parameter to 1 (True) enables "black hole" routers to be detected, however it also increases the maximum number of retransmissions for a given segment. In most cases you'd want to keep BHDetect to 0 (False).
EnablePMTUBHDetect="0" (DWORD - boolean, valid settings are 0-->False and 1-->True. Recommended setting is 0)
This parameter controls whether or not SACK (Selective Acknowledgement) support is enabled, as specified in RFC 2018. SACK is especially important for connections using large TCP Window sizes.
SackOpts="1" (DWORD - boolean, recommended setting is 1. Possible settings are 0 - No Sack options or 1 - Sack Option enabled).
This parameter determines the number of duplicate ACKs that must be received for the same sequence number of sent data before "fast retransmit" is triggered to resend the segment that has been dropped in transit.
TcpMaxDupAcks="2" (DWORD - range 1-3, recommended setting is 2).
Additional Related Parameters
The additional TCP related parameters are not necessary in most cases, and you shouldn't expect any drastic improvements, however we added them for those of you who like experimenting. You might be able to gain that last bit of performance, or customize your behavior even more with those. Keep in mind you should familiarize yourself with what the parameters mean and how they affect your connection before changing their values
Setting MTU overrides the default MTU for the network interface it is added to. Note that if EnablePMTUDiscovery is set to 1, TCP will use the smaller value of this local MTU and the "Discovered" MTU of the underlying network connection. If you'd rather use only the MTU value specified here, you'd have to disable PMTUDiscovery, which would prevent your system from detecting the network MTU.
MTU="1500" (DWORD, valid range is from 68 to <MTU network of>).
Windows 2000 Web Patch
According to the HTTP specs, only limited number of simultaneous connections are allowed, while loading pages. To increase that number, you can add the following entries to the Registry (they are not present by default):
Note: Keep in mind that although those values work fine in most cases, they exceed the HTTP specs and therefore might cause problems with some websites. If you experience problems, just remove the entries. While these entries might improve web page loading considerably, they tend to strain webservers more and have no effect on throughput.
Alternatively, you can download a patch from speedguide.net that will add these entries for you automatically from the Downloads section .
Posted in Computers & Tech / Networking
Author: techocian Total-Replies: 14
If I'm not wrong, a hub is used in the center of a network where data flow is transfered around like a big spider web. The router splits the internet connection to the computers connected in the network but it doesn't mean that you can transfer data through from the computer-router-computer. I tried that and it doesn't seem possible.
From my knowledge i believe a hub should be like a router of sorts but it doesn't work with certain types of networks. I use a wireless network with a Cable modem (Motorola), wireless router, network router (2 telephone ports for cable phone connection), and finally the wireless adapter itself to your computer. I'm trying to transfer data from one computer to another but it doesn't seem possible for my computer to interact with anything other than the router itself. I believe it's supposed to be able to work because hackers who tap into your UNSECURED wireless network (If you didn't secure it) may be able to see your every doings. So how do i do it?
Posted in General Discussion / Computer Talk
Author: FeedBacker Total-Replies: 13
As we speak I'm backing up an AComdata 320gig drive that's started acting really funky. I've had two IBM deathstars blow up on me, and I generally smell the death as its coming, and it come come quick, so you always have to act quickly. At this point, I've had maybe one cd/dvd fail out of hundreds, so I'm going back to burning discs. THis HD crap is out of hand. Its good to have external hard drives and burn backups if you're someone with data that can not be lost. This is the absolute achilles heel of digi photo. With slides, and negs, you always have the originals, unless they burn up, much less likely than fricking HDs, which I think by nature will all fail after 5 years. My Acom320 is less than a year ago. I'm not impressed.
Posted in Computers & Tech / Networking
Author: akijikan Total-Replies: 39
Wired LAN is faster and much more secure, since you're not broadcasting anything through the air. That means anyone who wants on your network needs a lin connection, they can't just park in your driveway and get on it.
Wireless LAN is near painless to set up though. No wiring needed and you can have a network up and running in no time. It's also not that hard to make it fairly secure through use of passcodes and such.
If you want to secure a wireless connection here are some steps you can take. They are from this website, visit it to see what I shortened with elipsies.
QUOTE (http)1) Don't use TCP/IP for File and Printer sharing!
Access Points are usually installed on your LAN, behind any router or firewall you may be using. If someone successfully connects to your Access Point...
2) Follow secure file-sharing practices
3) Enable WEP Encryption
802.11b's WEP encryption has had a lot of bad press lately about its weaknesses. But a weak lock is better than no lock at all...
4) Use WEP for data and Authentication
Some products allow you to separately set the Authentication method to "Shared Key" or "Open System"...
5) Use non-obvious WEP keys and periodically change them
While the limitations that some wireless client utilities have don't help...
6) Secure your wireless router / Access Point (AP)
Your router or Access Point should require a password to access its Admin...
7) Disallow router/ AP administration via wireless
Unfortunately, this feature is usually only present in "Enterprise-grade" APs...
8) Use MAC address based Access and Association control
Previously available only on "Enterprise-grade" products...
9) Don't send the ESSID
ORiNOCO and Apple call the ability to stop their products from sending out the...
10) Don't accept "ANY" ESSID
ORiNOCO and Apple's "closed network" feature also won't accept connections from clients using the default "ANY" ESSID....
11) Use VPN
Of course, if you really don't want to take chances with your data...
I didn't mean to submit the above reply, I still had more to go so here it is:
Typically your speeds on a wired network are going to be much quicker. Most ethernet cards today are 10/100 Mbit/sec and 1000 Mbit/sec is becoming increasingly common (especially in corporate fields).
Wireless has two standards and a third that is going to be introduced soon.
802.11b is 11 Mbit/sec
802.11g is 54 Mbit/sec
There are also some "Pre-N" products (referring to 802.11n) that are labeled as such because the maker is almost certain that the MIMO (Multiple Input Multiple Output) technology deployed by them is going to be used in the 802.11n standard. The current "Pre-N" products do deliver better speeds than their b and g counterparts while maintaining compatibility with them. Pre-N products are also often capable of further range. PC world tested a belkin router and card that could communicate over 50 feet. Much better than b or g. However when the 802.11n specifications are finalized, they likely won't be compatible with these "Pre-N" products that manufacters are developing outside industry standards.
One other thing that should be noted about wireless is that the weaker the signal you have (be it becaouse of distance or walls, etc) the slower overall rate of transfer you'll achieve.
So after all that information, to answer your question about which is better, like most things it depends on what you need.
Wireless is good if you're mainly interested in sharing a broadband connection in your house. The fastest home-consumer broadband options commonly top out at 8 Mbit/sec and are usually operating under that. That speed is within the capabilities of wireless connections.
However, if you are going to move a lot of data from computuer to computer, you are going to feel limited by wireless. Even though 802.11g is max of 54 Mbit/sec, you usually see transfers around 20 Mbit/sec average. If you're moving gigabytes of data between computers, a 1000 Mbit/sec wired LAN is going to serve your purpose much better than wireless.
Those who are security freaks should also stick to wired. While you can secure a wireless network, there have been cases of some wireless security measures being broken.
Hope that answers your question!
Posted in Computers & Tech / Operating Systems / GNU/Linux
Author: Jeigh Total-Replies: 19
First, welcome to the world of linux.
Second of all you can only technically "dual boot" if you INSTALL linux. Let me explain...
When you install linux it is actually on your system obviously. It has its own filespace on your hard drive and then you install a piece of software that is triggered upon starting your computer (a boot loader) which lets you choose an operating system to actually use for this session. Either by dual booting or using a live cd, windows remains intact on your system, but dual booting involves having both installed The advantage of having Linux actually installed is that it is much quicker and more responsive, lets you more easily save data to the hard drive (as you have designated space to store data instead of drives that are hopefully a compatible file type) and easier to keep updated.
Next are live cds, these basically, as you probably picked up, run straight off the cd. They don't actually install files onto the hard drive so you can use much of the functionality of linux without over writing anything on your HD. Now this is good for testing purposes and other maintenance thing or trying out new distros, but if you plan to use this OS as a primary system OS then you should get a dual boot setup ready. Many live cds now come with most applications you would want for basic tasks but eventually you'll want to try new apps and this is where having an installed linux OS comes in handy. Live cds are pretty amazing stuff, especially the most recent batches, but for long term I'd go with partitioning your HD and installing linux alongside windows.
Posted in Computers & Tech / Operating Systems / Windows (All Versions)
Author: Chesso Total-Replies: 13
Well some games are surprisingly slow at loading data when you change maps and such, one game that comes to mind is Vampires The Masquarade Bloodlines, it takes forever to load just small places and the main areas are a real pain.
Plus all they tell you is that you have to have a 1400mb swap file, yeah real great programming... anyway it's probably not worth it as others have mentioned, most of those silly tweaks don't see any visual benefit anyway.
Posted in Computers & Tech / Hardware Workshop
Author: FeedBacker Total-Replies: 17
I love the zen vision m
Battle Of Music Players: iPod vs. Creative
My brother has a Creative Zen Vision M 30gb. I use it quite often and it is great. I can go to bed, watch a DivX video, not a "poopy" .Mp4. Even after watching a full length movie, it still has 3/4 of a battery charge left. Also, with the a/v cord output to the TV, I can store many excellent quality videos and not need to waste money on DVD+are's. Another great feature is the ability to right click files and click "Send to Device: Media Library" instead of having to hop on crappy iTunes.
Also, in order to keep data on an iPod, does it have to be on the computer harddrive at all times?
Posted in Computers & Tech / How-To's and Tutorials / Programming / PHP
Author: Mordent Total-Replies: 3
Hey all, after reading through a fair number of tutorials on this subject I decided to write a pretty detailed one myself. Apologies for those who don't like my structured layout, it's just the way I do things.
Title: Creating a PHP Login Script
Objective: To go through a series of basic steps required to create a method of user registration, login and permission management using PHP and MySQL.
Notes: The information is designed to work fully on AstaHost's hosting plans. It was designed and developed using WAMP5 (WampServer Version 2.0) with settings configured to match those used by AstaHost (magic quotes and whatnot).
Login scripts are a fairly commonly covered topic in PHP tutorials but nevertheless one that gives a fantastic initial grounding in both PHP and in manipulating databases. MySQL is the database of choice for this tutorial as it's particularly easy to use with PHP and works brilliantly on AstaHost's servers. Where possible I'll give instructions tailored to AstaHost, but 99% of the actual work was done on a local server so apologies if any of the steps aren't quite the same.
Step 1: Creating the Database
If you already have a database created that you can use then you can skip this step.
Any good login script (registration/login/permissions) needs a database to store the user information. Creating one is relatively straightforward. Navigate your cPanel until you come across MySQL Databases (or similar). In it is a very simple interface to let you create both databases and MySQL users. Normally you'll want a user for each site you create. AstaHost appends whatever name you decide to give your user to your cPanel username followed by an underscore. For instance, if your cPanel username was "foo" and you named your MySQL user "bar" then the full MySQL username would be "foo_bar". There is a limit on the length of the usernames you use. I'm not entirely sure if the limit is based on your cPanel username (i.e. a character limit to "foo_bar") or just the MySQL username suffix (i.e. a character limit to "bar").
For the purposes of this tutorial I'm going to use "fred" as my cPanel username and "tutor" as my MySQL user, giving a full MySQL username of "fred_tutor". Naturally you should replace this with whatever you end up using throughout the rest of the tutorial. Make sure you note the password you use, as it'll be very important later on.
After you've created your MySQL user you need to create the database itself. Similar to the MySQL usernames, your database name will have the prefix of "foo_" (see above) to it. Choose something sensible, most likely based to fit your entire site. I'm going to be using "fred_tutorials" as mine throughout this tutorial, so obviously replace it with whatever you use.
You need to give the user you created permission to manipulate the database, so (using the cPanel appearance at the time of writing) scroll down to Add User To Database. Select the user and database from the dropdown menus and hit Add.
Step 2: Creating the Table
Your database is most likely currently empty (certainly so if you just created on in Step 1), so we need to add a table to it. One of the easiest ways to add one is using phpMyAdmin, which is found by navigating your cPanel (near MySQL Databases from earlier). This page lets you do all sorts of things (in fact, pretty much anything) to your MySQL databases. In AstaHost you can't create or delete databases, but other than that you've got pretty much free roam.
So, on the left should be the name of the database you just created. Clicking on it once opens up a page with information about the structure of the database. Currently this will be empty, as you haven't put any tables in yet. Let's add one now. There are two ways of doing this: the user-friendly way or the more complicated way that lets you see what you're really doing. I'll mention the first one, but as I always use the second I'm not going to focus on it too much. Simply put, it's a way of making the functionality look prettier.
Next to the "Structure" tab is a tab called "SQL". This tands for "Structred Query Language", and clicking on this lets you run queries (i.e. tasks or operations) on your database. The query we're going to run is the one below (note that the query is case-insensitive, and you should be able to copy and paste pretty much from this if you need to):
CODECREATE TABLE `users` (
`id` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
`username` VARCHAR(256) NOT NULL,
`password` VARCHAR(16) NOT NULL,
`email` VARCHAR(256) NOT NULL,
`active` TINYINT(1) UNSIGNED NOT NULL default '0',
`activation_code` VARCHAR(16) NOT NULL,
`admin` TINYINT(1) UNSIGNED NOT NULL default '0',
PRIMARY KEY (`id`),
So what does all of this do? Let's take it line by line:
CODECREATE TABLE `users` (
This bit is fairly self-explanatory. We want to create a table in the current database and we want to call it "users". Tables in your databases don't have your cPanel username added as a prefix, so the table name will actually be "users".
CODE`id` SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
This is the first "field" of the table. Its name is "id", which we'll be using to identify individual users later on. It is a "SMALLINT", or "small integer". Because we say that the field is "UNSIGNED" that means it can range 0 to 65535. If we'd left it as it was then it would have values in the range -32768 to 32767. We could quite happily use the standard-sized "INT" (for "integer") here, but a "SMALLINT" can have one of 65536 different values, so that should be plenty for most sites. If you need more then firstly: dibs on a small percentage of your advertising income (I'm sure I deserve it! ), and secondly you can use "MEDINT" (short for "medium integer") instead. "MEDINT" will give you 16777216 different user accounts, so that should keep most people happy. You can look here for more information on different numeric data types.
For the purposes of this tutorial, I'll be using a small integer.
The next part is "NOT NULL". This means that the all entries in the "id" field have to have a value and can't just be left as NULL. NULL means that absolutely nothing has been assigned to the value. It isn't the same as an empty string. We want every user to have an id, so we make sure it's "NOT NULL".
Finally, there's "AUTO_INCRMENT". Rather than having to worry about assigning each new user an id ourselves we let the database do the legwork and set the field to "AUTO_INCREMENT". Each new entry in the table will get an id one greater than the last. Provided you don't start manually playing around with the tables after people have started creating accounts (i.e. adding new users directly in or playing with individual users' ids) then this takes a fair amount of hassle out of it for us.
Also to note, the line ends in a comma. This tells it that we're done with this field, on to the next line! Technically lines aren't even necessary, but it makes for easier reading so they are highly recommended.
CODE`username` VARCHAR(256) NOT NULL,
Our next field is "username". This one is a "VARCHAR" type field, or "variable length string". This basically means you can have text in there up to a maximum length of the number in the brackets. In this case the maximum string length is 255 characters. That should be plenty for usernames, so no need to go any bigger. Again, we don't want NULL usernames, so we make sure the field is "NOT NULL".
CODE`password` VARCHAR(16) NOT NULL,
This one's a bit more interesting. Clearly this is where we'll be storing the user's password, but all good sites encrypt the passwords rather than storing them directly. The number in brackets next to the "VARCHAR" effectively limits the length of the string to 16 characters, but as we'll be encrypting the passwords anyway (I'll be showing you how to do that later) this limits the encrypted string to 16 characters. Again, not really worth bothering yourself too much over, it'll make much more sense later on.
CODE`email` VARCHAR(256) NOT NULL,
Knowing the user's email is very useful for many sites, not least for account activation (see later). This is simply where we'll be storing the users' email addresses.
CODE`active` TINYINT(1) UNSIGNED NOT NULL default '0',
We're back to integers with this "TINYINT", the "active" flag. It's got a number in brackets again, limiting the length of it to 1 bit. As we also say that it can't be NULL, and that it's "UNSIGNED" (not that that really matters in this case) it has one of two states: 0 or 1. Also note the default state of "0", meaning that when a new user is created we don't have to worry about setting that to "0" as it will already be done for us. Default values are very useful and save both security slip ups (see later) and effort. This flag will be used to store whether the user has activated their account. If it's "0" then they haven't (meaning that they shouldn't be able to log in yet) and if it's "1" then they already have, so all is well. This field goes hand-in-hand with the next one.
CODE`activation_code` VARCHAR(16) NOT NULL,
The activation code is another VARCHAR, again limited to 16 characters. You know those random activation codes you get in emails when you sign up to a new site? This will be used to store the users' one of those. If the active flag is 1 then it will never be needed again, but we need to store it somewhere while the active flag is 0.
CODE`admin` TINYINT(1) UNSIGNED NOT NULL default '0',
Recognise this sort of entry? Yup, it's another flag. This one tells us whether or not the user is an admin. If 0 then the user is a standard member, if it's 1 then the user had admin rights. You can expand this field to include a number of permission settings by, for example, changing the name to "user_level" and increasing the number of possible states by increasing the length of the TINYINT. This makes for more interesting checks later on, and may be something I add to expand upon the tutorial later, but for now this is what we'll be running with.
CODEPRIMARY KEY (`id`),
This line is a bit more complicated, and it helps if you know what a "primary key" is. In effect, it's a way of sorting or identifying individual entries from others, and in this case we use the user id ("id" field) to do this. It isn't vital that you understand this, but it helps.
We don't want users running around with the same usernames, so we make sure to set it so that each one is unique.
This closes the bracket from the first line and sets the storage engine to use. In this case we'll be using MyISAM. Other options include InnoDB and range of other ones. The pros and cons of each are pretty much irrelevant at a basic level. Probably just best if you accept that you can use whichever takes your fancy until you know the ins and outs of them.
One thing you may have noticed as you go through this tutorial is the constant limitation of the length of the data that we want. For example, we limit the "active" field to a TINYINT of length 1 (i.e. 1 or 0). If we didn't specify the lengths of these fields then they'd use up a lot more room in the database. A TINYINT, for example, is 8 bits long (i.e. a byte), but we only need one of them. If we didn't limit its length that'd be 7 bits wasted per user, which is a fair amount considering how much you're using (12.5% of that byte). It makes sense to think a bit more about how long you actually need your database to be, especially when you have limited storage space to spare.
And that's our table created! We now have a database that we have access to which contains a table structured to our needs. Now that that's done we can actually start looking at the PHP and HTML code.
This is the intital post in my tutorial, and I'll get to writing up the rest later. I may change the odd bit as I realise that I need another field in my database etc. If you've got any comments or spot a problem with the database just give me a shout (preferably by PM) and I'll tweak it.