|
I just happen to have this handy that may be of interest
[edit] As Shameel pointed out these may be illegal books and I respect and appreciate the work put in by authors to encourage theft. [/edit]
Last modified: 2hrs 26mins after originally posted --
|
|
|
|
|
CP is a place for ethical programmers. Do not post links to illegal free ebooks 
|
|
|
|
|
I did not even look into the details, I got the link right here and thought they were teaser type books, thanks for the heads up. I agree with you and the authors put in way too much effort for me to devalue their work by encouraging theft.
|
|
|
|
|
I appreciate your conern, and agree with you about IP theft colpletely, but if you couls at least post the title, I might be able to actually buy it. 
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
"Pro ASP.NET for SQL Server: High Performance Data Access for Web Developers" by Brennan Stehling.
|
|
|
|
|
Great! That's a good start, I think, although I don't plan to use web access yet - just a dedicated C# client accessing a central SQL server in the office. My whole plan is to make this equipment tracking job so simple I can hand it off to someone else.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Is there such a thing? Access ships with a built in documenter, which I find handy in print form to use as a reference when I'm trying to wrote code to manipulate it. I never can remember all the field names and types 20 minutes after I create a database...
I can get a list of field names using a select query against 'information_schema.columns' and I can print that, but it's not a very convenient format; all I want is the field name, type, and width (for text).
Is there a freely available tool to simplify this task?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
There's an article right here on the Code Project which might help:
SqlDoc: Document your SQL Server database[^]
Or, a quick google for "sql server free schema documentation tool" brings up over 85,000 results, at least one of which might be helpful.
DBScribe is good, although it's not free. But at just $99 it's not exactly going to break the bank. It might be overkill for what you're looking for, though.
|
|
|
|
|
Hey guys, as u guessed by now, I have a MDF and LOG file which were created in SQL Server 2008, and currently I don't have that. Is there anyonre who can give me an email address so I can send my files to him and he sends me the script, that way I can generate it in 2005 !!! I ve done alot of searching and found this as the only way !!!
Thanx in advance
|
|
|
|
|
Am trying to understand what your question.its not clear please try to explain again
Vuyiswa Maseko,
Spoted in Daniweb-- Sorry to rant. I hate websites. They are just wierd. They don't behave like normal code.
C#/VB.NET/ASP.NET/SQL7/2000/2005/2008
http://www.vuyiswamaseko.com
vuyiswa@its.co.za
http://www.itsabacus.co.za/itsabacus/
|
|
|
|
|
I want to send someone an MDF and LOG file, have them attach the file to their server, then script out the entire database and return the script to you.
|
|
|
|
|
You want to send someone an MDF and LOG file, have them attach the file to their server, then script out the entire database and return the script to you.
You might want to elaborate, the size of the database would be rather important.
Also, why not install SQL Express 2008 and do it yourself (other than the absolute nightmare that installing SQL 2008 is).
|
|
|
|
|
exactly ! Thats, I figures if someone has it installed already why go through all the trouble installing it!!! Its about 60 MB !
K
|
|
|
|
|
60mb is the least of your problems when installing SQL 2008, there is a problem in the installer that cannot find dotnet 3.5 sp1 somewhere
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hav you tried using sql2008 express? Its free, and I think you would be able to do what you need.
Bob
Ashfield Consultants Ltd
Proud to be a 2009 Code Project MVP
|
|
|
|
|
What is the compatibility level of the database ? If it was set to 90 or lower, you could still attach it to SQL Server 2005.
|
|
|
|
|
When I try to attach it, I get this error saying that my server supports 661 and lower and the file I'm trying to attach is 665 !
|
|
|
|
|
It means that you cannot attach it to an SQL Server 2005 instance. Why don't you try SQL Server 2008 Express. Its free 
|
|
|
|
|
Use Joint Venture Booster And Gain More With Less Effort. Easily Win JV-Partners And Let Them Promote Your Products On Their Thank-You-Pages. Simple To Install And Admin, Yet Highly Customizable. Unlimited JV/Ads. Works With Any Affiliate Program. Visit us at: http://www.clicknearn.net/3152-72.html
|
|
|
|
|
I am trying to decide on how to implement the following database for a stock market program for historical data, using SQL Server.
Originally my thoughts were to have data columns with adjusted data (for stock splits) as follows:
Example 1:
DateTime,
DayOpen, DayHigh, DayLow, DayClose, DayVolume,
WeekOpen, WeekHigh, WeekLow, WeekClose, WeekVolume,
MonthOpen, MonthHigh, MonthLow, MonthClose, MonthVolume
But more recently my thoughts are to load the database with only historically real information, with a variable to calculate the split info as follows
Example 2:
DateTime, Open, High, Low, Close, Volume, AdjustmentVariable
I will be storing current needed data in C# datasets and only access historical data when needed (changes such as stock splits, new symbols to track, etc.). Everyday I will update the database with the current data and change the AdustmentVariable as needed when the stock splits, then reload new data to the datasets.
Considering speed, ease of use, memory, etc. what would be the better way to proceed with this.
1. Use the second example using stored procedures, calculate and retrieve data when requested per stock.
2. Use a combination of the two above and calculate data weekly, monthly and retrieve data as needed, will this be memory inefficient with all the unfilled dates during the middle of the week, months.
3. Setup a Data Warehouse which will calculate the data daily after updating and I retrieve as needed.
Any advice will be greatly appreciated,
Michael
|
|
|
|
|
As a general rule, you shouldn't store any value that you can calculate... HOWEVER... the one main instance for breaking this rule is where the volume of data is large and the calculation needs to be performed frequently, therefore making it a better option to store the calculated values for speed and efficiency purposes (even if doing so adds a level of complexity - ie: maintaining the stored calculated values to ensure they are always correct)
If the volume of data is low, or the rate you are expecting to calculate the information is infrequent, then go with the first rule of not storing values that you can calculate and then calculate them in real time as you need them.
HTH...
|
|
|
|
|
I will have a database setup for every exchange this adds up in the US to 30,000+ securities. I think example 1 does not seem like a very efficient way to handle the problem. What are your thoughts about using a data warehouse to calculate/accumulate the weekly, monthly, etc. data, this seems like it will be a much easier way. to gather this info. Using a stored procedure to get this info would be much more difficult. Though I would only need to retrieve the info when needed.
Michael
|
|
|
|
|
MAW30 wrote: I will have a database setup for every exchange
Why would you do this rather than simply have some kind of relationship to a table of exchange information? If the data is in the same format, this would save you some effort - adding a new exchange would be as simple as adding a single record into the exchange table and then populating the data - no code changes required.
MAW30 wrote: using a data warehouse to calculate/accumulate the weekly, monthly, etc. data
For historical data (that is presumably never going to change) this is an excellent idea. See Mycroft Holmes' post below.
|
|
|
|
|
I am not sure what you mean by the statement "Why would you do this rather than simply have some kind of relationship to a table of exchange information".
How would I go about doing this.
Michael
|
|
|
|
|
You said that you would have a separate table for each exchange. That's one option.
Another option would be to have a single table for the stock data you were speaking about (daily high, low etc), and (assuming that the data structure is the same for each exchange - which I'm sure it would have to be?) a foreign key that links the data to a second table that holds the exchange information.
eg:
Table 1 - tblStockData
StockDataID
StockDataStockCode
StockDataDailyHigh
StockDataDailyLow
etc etc
StockDataExchangeID -- Link this to ExchangeID in table tblExchange
Table 2 - tblExchange
ExchangeID
ExchangeName
etc etc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
