|
Same answer still applies.
1. It depends on what you 'mean' by "symbol"
2. If and only if the answer to 1 means that unicode is suitable then you have the following choices
a. Set up the database to accept unicode.
b. Encode the data into the character set that the database does support (probably to base64) and live with the fact that you won't see the characters in the database itself - you will need to use your application.
|
|
|
|
|
@jschell by symbol i excatly means what we use in maths i mean symbol to represent inegration and diffrenciation i hope u can understand what i mean to say..
|
|
|
|
|
I understand what a mathematical symbol in mathematics means.
However that has nothing to do with how you represent the idea on a computer.
For example I could use a paint program to create a formula and then store it in a database.
Or, as I suggested, unicode has mathematical representations.
There are other possibilities.
It is up to you, based on your business needs, to first determine the form (the data on the computer) that your representation will take.
|
|
|
|
|
pankaj3086 wrote: how to insert mathematical symbols like integration diffrenciaton symbols in database.so that it can be redable in .netframework when it is retrived from databse
Can you post an example? Show us what it is that you want to store, 'cause as it is, you won't get much valuable answers.
All text-encodings are supported. No, text does not support all math. So, how are your users going to represent their content?
MathML[^] would be a good choice, and you can store it in a VARCHAR column.
Bastard Programmer from Hell 
|
|
|
|
|
I agree with Eddy. You don't need to store the actual symbols in the database (although you can if it makes sense). The symbols are more a matter of UI.
I second using XML or similar to persist the concept of the expression.
|
|
|
|
|
I'm interacting with a dBase III file using Microsoft's ODBC dBase driver. I can create a CRecordset object and iterate through the table just fine (populating controls on a dialog and such). When I went to count the rows/records in the table using SELECT COUNT(*) FROM ACTY, the code kept throwing exceptions. Based on the error messages in the debug window, I suspected column 1 (type Date) was at fault. I managed to insert another column into the table of type Text (Numeric type also works). The COUNTing code now works fine. My question is, why? I could iterate the table just fine when the first column was a Date, but not count the rows. Is there a rule that states what types can be in the first column and what types cannot when counting? As there are hundreds of these database files in use, injecting a "dummy" column into them just for the sake of counting is not a solution.
[edit]
I was able to create a dBase 5 table and it exhibited the same behavior. When I added the extra column, however, no exceptions and counting worked fine.
[/edit]
[edit2]
I was able to successfully count records in the table using the ODBC API (e.g., SQLDriverConnect(), SQLExecDirect(), SQLGetData()) rather than CDatabase and CRecordset.
[/edit2]
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
modified 19-Mar-12 10:45am.
|
|
|
|
|
I'm surprised at your findings. The COUNT function shouldn't care what columns are on the table or what datatype they're made of. May be a bug with the driver?
If I were you, I would suspected that USER was a keyword and would have tried to rename the table and see if it worked instead of adding a new column.
|
|
|
|
|
Shameel wrote: I'm surprised at your findings. The COUNT function shouldn't care what columns are on the table or what datatype they're made of. May be a bug with the driver?
I'm not familar enough with it one way or the other. If you step through the code, however, the columns are definitely being bound (in the set's DoFieldExchange() method).
Shameel wrote: If I were you, I would suspected that USER was a keyword and would have tried to rename the table and see if it worked instead of adding a new column.
There are actually two tables: ACTY and USER. The USER table works fine with no changes, both iterating and counting.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
modified 18-Mar-12 16:58pm.
|
|
|
|
|
DavidCrow wrote: dBase III
I do hope that you have a copy of that database is a more recent format?
Bastard Programmer from Hell
|
|
|
|
|
If I can't operate on it directly, I will consider converting it. Given the constraints on the client side, that would be a last resort.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I suggest you use Microsoft Visual Foxpro ODBC Driver[^]. It has full compatility with other xBase product (including dBase III+), it is newer, and it has much better handling with SQL queries.
hth,
foxyland
|
|
|
|
|
I'm working on a WPF app that has user profiles. The profile contains the user's picture. Any reason not to store the image in the Profiles table?
Never done this before. Suggestions/comments appreciated.
Thanks
Everything makes sense in someone's mind
|
|
|
|
|
Kevin Marois wrote: Any reason not to store the image in the Profiles table?
I don't have any; that's what I'd do. If you're not already, you may want to resize the images to some standard before doing so.
|
|
|
|
|
Ok, thanks
Everything makes sense in someone's mind
|
|
|
|
|
If you were working on a webapp, then it'd be sweeter to have them on the server directly so that the browser can cache them.
Outside of that environment, I prefer to store those things in the database. That way you can backup all the data that belongs together in a single document.
Bastard Programmer from Hell
|
|
|
|
|
Actually, I'm working on an app thay will have WPF, WinPhone, and Web UI's, so maybe storing them on the server is best.
Everything makes sense in someone's mind
|
|
|
|
|
The problem I have with that is if someone replaces a file with one you don't expect.
|
|
|
|
|
PIEBALDconsult wrote: The problem I have with that is if someone replaces a file with one you don't expect.
What does that have to do with how they are stored?
|
|
|
|
|
The file system is less secure.
|
|
|
|
|
PIEBALDconsult wrote: The file system is less secure.
I doubt that is relevant in a system that needs to be secure.
If one does nothing but assume that a database is "more" secure than a file system with no other concern for security then they will have problems. And one a real security policy in place any real differences in implementation of systems at this level becomes much less significant allowing one the freedom to base decisions on other business needs.
|
|
|
|
|
I'll stick with the more secure solution regardless. It's like putting things in a bank vault rather than relying solely on the security guard at the door.
|
|
|
|
|
PIEBALDconsult wrote:
I'll stick with the more secure solution
regardless. It's like putting things in a bank vault rather than relying solely
on the security guard at the door.
Not at all. At least not at most banks, because your analogy is not a complete statement of the security policy in place at the bank.
For instance...how is the vault secure if the door to it is left open, the front door to the bank is left open and there is no active security monitoring system in place?
And note that several years ago one large study found that 90% of security problems with actual losses originated internally within the company.
|
|
|
|
|
jschell wrote: originated internally within the company.
Which is my point too. Generally, more people have access to the file system than to the database. A no-longer-gruntled sys admin could replace individual files, but not alter the contents of the database.
|
|
|
|
|
Kevin Marois wrote: Actually, I'm working on an app thay will have WPF, WinPhone, and Web UI's, so maybe storing them on the server is best.
I'd still store them in a database 
You'll want a specific folder to store the user-pictures; you don't want to store them between "all other" pics like logo's and the like. This gives also the advantage that you can delete everything in this path and rebuild it with the info from the database, without touching other graphics.
Bastard Programmer from Hell
|
|
|
|
|
For small images database is probably best, simply because it is going to be easier to implement.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
