|
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
|
|
|
|
|
If you have a long time series, you can have hundreds of million or even billions of rows if you have multiple sources (e.g. > 100 GB size). How much memory will your database have? It likely is not a good idea to store weekly or monthly data on the database for performance reasons.
You should write stored procedures and functions to return the data that you want.
|
|
|
|
|
Btw, your main concern setting up the database should be dealing with the issues around ticker changes, cusip changes, stock splits, dividends, calculating cumulative returns, etc.
|
|
|
|
|
As Damian suggested, storing the calc values is technically incorrect but may be valid for performance reasons, this will depend greatly on your usage of the data.
I would probably set up 2 structures, the current data in a normal relational database using views to supply the calcs and a data warehouse with a properly designed cube to handle the historical data. This has been done many times, I'd be surprised if there is not a case study out there on the exact structure you are proposing.
|
|
|
|
|
Your longest time series will have slighly more than 12,000 datapoints assuming you download data from 1970, which is google's start date.
Your dataset using option 2 should be at most 1 GB per 2,000 stock ID assuming you are only loading data from a single source and chose the right data types. So if you have 16+ GB of memory, the entire database might reside in memory and you would have associate performance pickups.
Assuming you do not have that powerful of a machine (otherwise, your firm might already have this data), then using a combination of option 1 and 2 might be best for performance of your application. You store historical data in option 2 format and precompute the data in option 1 format for the next business day. I am assuming that you are not incorporating in live data right now. The precomputed data will not take up much space and can be overwritten each night or as needed (e.g. you could add a time stamp to option 1's table. If the time stamp is too old, then you call a function to fill the table before returning results.)
modified on Sunday, November 22, 2009 11:26 PM
|
|
|
|
|
I am trying to create a TFS report which requires MDX. I am making a report that requires a calculated member. I am not 100% sure how this is done. The member i am trying to do is a difference calculation.
For example:
Table
Sept 1 Sept 2 Sept 3
Actual 0 32 58
Remaining 163 140 132
Difference 0 9 50
The calculation for the difference is as follows:
Actual Effort for that day - (Work remaining previous day - Work remaining that day)
32 - (163 - 140) = 9
Can someone help please? 
|
|
|
|
|
Without any table definition of columns, it's hard to guess at what to provide. As a suggestion, though you may need to join the table on itself in order to have access to "today's" values and "yesterday's" values.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
