Lol agree with ddanbe, like we told you yesterday use tbSendText.Text
And just to shed some light on what the other guys are saying about the crlf (\r\n), the socket you are connected to needs to know when you are done sending. Since you can send 5 bytes, then later 10 bytes for example, you must tell the connected socket when you are done. The crlf typically is used to say "i am done", then the response is sent back from the connected socket.
As long as you are on mysql 5 you can do it that, and pretty sure in 4 as well. Just ensure the zone table is out there with entries.
SELECT COUNT(*) FROM mysql.time_zone_name;
The reason why I would say to do it in the app code is that you always know your datetimes are coming across as utc, and not already timezone formatted. It is one of those things you can go either way on, but from experience I have found it most consistent to let the database simply store and retrieve the data, and reside your formatting (timezone and dst in this instance) in the app code.
"Four constructors: one for the number of degrees, one for the scale, one for both degrees and the scale, and one default constructor. For each of these constructors, assume zero degrees if no value is specified and Celsius if no scale is given."
Here are the constructors, read your instructions on what to do with them
public Degree(){
}
public Degree(float degree){
}
public Degree(char scale){
}
public Degree(float cDegree, float fDegree, char scale){
}
You only need to install workstation components as part of the installation. I don't know what you are meaning the other ones will have problems later, each part of the installation can be completed later by only selecting it with no problems, if thats what you are meaning.
if you are doing it in code, make the method accept an enum value
if you can do that, agree with lizr and validate what is passed in, might want to add an enum value of unknown to your list and use it if an enum isn't valid for the specified int
Whenever you backed up the original database make sure to backup stored procedures, views, and users along with it. Then do the restore and they should be there.
A stored procedure is a set of sql code for the database, not a column.
You can find it in the programmability section for the database.
The security on the stored procedure is separate from allowing the login, find the stored procedure going into programmability -> stored procedures for that database
Here's the code I use without any problem when passing byte arrays back and forth from java to c#
//Assign these some values
byte[] byteImage;
string savePath;
FileStream fileStream = new FileStream(savePath, FileMode.Create);
//attempts to write file to local machine
fileStream.Write(byteImage, 0, byteImage.Length);
fileStream.Close();
You can set it to where you can connect with no password, or with a password, but only from the person doing the logging in. You can then observe the desktop and interact if need be.
I would recommend to set up possibly inside the uploads directory, you just want to be sure that permissions on this images directory aren't able to access your other directories, because you are allowing users to write to them.
First part. You are going the right route by storing files on the server and paths in the database. You should create a main image directory and possiblty have your images table have a subpath off of that. I'm sure each row will have an 'owner' or client column, so each client can have its own subfolder for images. Then each client, will have a house id lets say. So you can use something like this /images/clientid/houseid/imagename.jpg
Second part. This will work a little different. You will only want to load content, and not necessarily the entire webpage from the database.
If you can be a little more clear from the second part feel free.
Also be sure to optimize your code as well ie use stringbuffer instead string +, you know the usuals. When you are comparing characters, you might be running into speed and performance issues when you get into the larger documents.
Mainmenu mainmenu = new Mainmenu(playername);
mainmenu.run();
// in the mainmenu class
private String playerName;
public void mainmenu (String playername) {
this.playerName = playername;
}
public void run(){
while (makerestart <= 200000);
//... continue on with your original mainmenu code
}
Static is meant to be thought of as that it doesn't apply to a specific instance of the object or class. As java addict's example, you can printMyName at any time without creating an instance.
You could possibly tell them their account is inactive, and go through some sort of steps to reactivate and set their active flag back to '1' so their data won't be lost.
There is really no right answer on how long to keep the information. A lot of times I would never delete unless it became an issue of database size or critical information.
Also, assuming you have some sort of houses table with a user_id owning the house. If you physically delete the user row, then you will have to delete house row as well as long as constraints are in place. Therefore I would say its not normally that important to delete the data, but it can be under the right circumstances.
i mean to pull back the active column from the user table
for example lets says a user places orders
table orders order_id user_id order_number
then in the query you can do something like this
select o.order_id, o.order_number, o.user_id from orders o
inner join
users u
on o.user_id = u.user_id
where u.active = 1
like for example if you let a user to see orders without logging in, you would want to join on the user table to make sure that they are still active before showing the results
Yes, same sort of update query as normal if you want to delete. This way also allows you to keep your database in tact and not worry about fk constraints on deletes, or a good way to recover data if it was 'deleted' (just set inactive).
Just remember if you are doing any joins on the user table or based upon a used_id to always add the active column to the query as above.
Add something like an active flag to the user. And in all queries when pulling users add where active_flag = 1 for active users, and the '0' user will not be pulled back. So this allows you to maintain the user still in the db, but not returned from queries to display in the website.
