data space used by a table in MSSQL Server 2005

How can I query (using TSQL) the data space used by a table in SQL Server 2005?

This is possible using SQL Serve Management studio. I can right click on table name and check the proeprties. But I want to write a TSQL script to check disk space used by all the individual tables in the database. How can I do that?

EXECUTE sp_spaceused 'MyTable'

|||

Thanks Arnie... sp_spaceused is what I was looking for.

sql

Data Source

I have a problem connecting Visual Studio 2005 to my DataBase file. I've downloaded northwind.mdf . Three weeks ago I installed SQL express and I used Visual Studio in the following manner: From server Explorer tab I choose Add connection.. , Change data source and I selected Microsoft SQL Server Database File (SqlClient), next I've selected my NORTHWND.MDF and when I pressed Test connection , it succeded. Recently, I've purchsed SQL server developer edition. The problem is when I follow the steps above I reveive:

An error has occurred while establishing a connection to the server, When connecting to SQL Server 2005, this failture may be caused by the fact that under the default SQL Server does not allow remote connections. ( provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

So , I've checked and changed remote connections to allow TCP/IP , but I receive the same error.

I've set up Visual Studio to SQL Server Instance Name : NAME , where NAME is the name assigned to my SQL Server. Worthless

The thing is it is working in another way : From server Explorer tab I choose Add connection.. , Change data source and I selected Microsoft SQL Server (SqlClient) , next I've selected server name to NAME , then Attach a database file . Test connection : succeded . This is because I do not have the northwind database attached directly in my SQL server ( and I do not want to ) .

Why with Developer edition I do not receive the same results ? Where is the mistake?

Thank you

Connecting to a database is a feature available only in SQL Server Express edition, but not in any other SQL Server version. This feature intention is to allow database applications development without the need to have a DBA who attaches the database files. For more information I would recommend to visit SQL Server 2005 Express Edition User Instances (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsse/html/sqlexpuserinst.asp).

If you want to use SQL Server developer edition, I would recommend attaching the database to SQL Server. For more information on this topic you can visit the following link: How to: Attach a Database File to SQL Server Express (http://msdn2.microsoft.com/en-us/library/ms165673.aspx).

Thanks a lot,

-Raul Garcia

SDE/T

SQL Server Engine

Data retrieval is much slower in RS than in management studio

A call to a stored procedure completes in 13 seconds when ran from within SQL Server Management Studio. A report whose data source uses the same stored procedure can take as long as 10 minutes to run. The same parameter values are used in both the direct call and the report. The execution log says almost all of that time is spent on data retrieval. How could that be? What might be the cause?If you didn't already, try profiling your sql instance right before you run your report. Have tsql statements shown so you can see a better breakdown of each command executing. This might show that the parameters used for the report are actually different than what you're expecting.|||I'll give it a try. However, looking at the Parameters column from the ExecutionLog table confirms that the values are the same. The report has the same parameters as the stored proc and simply passes the its parameter values along to the stored proc.|||

I set up a trace, launced the report and ran the SP from with SQL MS, then stopped the trace when the report came back. Instead of requesting a whole year's worth of data (which can take over 10 minute), I used a month. It takes about 15 times longer to run the report via RS than it does from within SQL MS.

When ran via RS, there are over 50x the number of reads.

From trace log:
This is the query ran from within MS:
exec SalesByDivision
@.beginDate='2006-12-31 00:00:00:000',
@.endDate='2007-02-03 00:00:00:000',
@.lyBeginDate='2006-01-01 00:00:00:000',
@.lyEndDate='2006-01-28 00:00:00:000',
@.storesListName=N'Comp stores',
@.departmentsListName=N'Owned merchandise',
@.storesCustomList=N'',
@.departmentsCustomList=N'',
@.delimiter=N',',
@.doNotRestate53WeekYear=N'0'
There were 10975 reads, 0 writes, and it took 1001 milliseconds

This is the query ran by the report server:
exec SalesByDivision
@.beginDate=''2006-12-31 00:00:00:000'',
@.endDate=''2007-02-03 00:00:00:000'',
@.lyBeginDate=''2006-01-01 00:00:00:000'',
@.lyEndDate=''2006-01-28 00:00:00:000'',
@.storesListName=N'Comp stores',
@.departmentsListName=N'Owned merchandise',
@.storesCustomList=N'',
@.departmentsCustomList=N'',
@.delimiter=N',',
@.doNotRestate53WeekYear=N'0'
There were 601409 reads, 0 writes, and it took 15326 milliseconds

|||

Did you try to just copy the exact text from the profiler? (to ensure that typo's and oversights aren't an issue)

Also, is the amount of system resources available possibly an issue?
Meaning, when running with just SQL MS, you are just using sql, but when you introduce RS, that's another program eating resources as well.

|||I notice you're not specifying a schema in your call to the stored procedure; do you have multiple versions of the SalesByDivision proc? If so, it might be defaulting to the one you want when you're connected in SQL Management Studio and an older or incorrect version when run under the context of the reporting services report. If not, I would trace the individual SQL statements as already mentioned and look for the statement(s) with highest reads to tune.|||

Thanks for the questions.

Yes, I copied the SQL from profiler then ran that in SQL MS.

These results are from a new production box. The system is consistently under load. Most reports that users are running are for very small date ranges and return within an acceptable time. However, reports with longer date ranges (the ones that managers and execs often run) are noticeby slower. Whether I run the SP from SQL MS or if I run a report, I assume the same resources are being used by RS.

|||There is only one version of the stored proc. For kicks I tried updating a report to include dbo. in front of the SP name. There was no noticable difference in load time.|||but add in t-sql commands to your trace. Do you know how to do this?|||

WITH RECOMPILE

Another one of our developers found a forum where someone had posted the same issue. Their suggestion was to add WITH RECOMPILE to our stored proc. After doing this we have experienced dramatic increases in performance with no unexplained slow periods. Also, before we added WITH RECOMPILE, the processing would occasionally be unevenly distributed between the eight CPUs on the SQL Server. One of the eight would get pegged while the otheres were not. After making the change we have seen an even distribution among all CPUs. Now it's taking the same amount of time to retrieve the data from the report - around 13 seconds.

|||Thanks for getting back with the solution buckenn. This was really helpful.|||

This is FANTASTIC!!

I was experiencing the same problem - the stored proc would run quickly, however, the report would take up to 15 minutes - and there wasn't much data being returned - fewer than 30 rows and only 15 columns. After adding WITH RECOMPILE to the proc, now the report generates in 15 seconds.

Data retrieval is much slower in RS than in management studio

A call to a stored procedure completes in 13 seconds when ran from within SQL Server Management Studio. A report whose data source uses the same stored procedure can take as long as 10 minutes to run. The same parameter values are used in both the direct call and the report. The execution log says almost all of that time is spent on data retrieval. How could that be? What might be the cause?If you didn't already, try profiling your sql instance right before you run your report. Have tsql statements shown so you can see a better breakdown of each command executing. This might show that the parameters used for the report are actually different than what you're expecting.|||I'll give it a try. However, looking at the Parameters column from the ExecutionLog table confirms that the values are the same. The report has the same parameters as the stored proc and simply passes the its parameter values along to the stored proc.|||

I set up a trace, launced the report and ran the SP from with SQL MS, then stopped the trace when the report came back. Instead of requesting a whole year's worth of data (which can take over 10 minute), I used a month. It takes about 15 times longer to run the report via RS than it does from within SQL MS.

When ran via RS, there are over 50x the number of reads.

From trace log:
This is the query ran from within MS:
exec SalesByDivision
@.beginDate='2006-12-31 00:00:00:000',
@.endDate='2007-02-03 00:00:00:000',
@.lyBeginDate='2006-01-01 00:00:00:000',
@.lyEndDate='2006-01-28 00:00:00:000',
@.storesListName=N'Comp stores',
@.departmentsListName=N'Owned merchandise',
@.storesCustomList=N'',
@.departmentsCustomList=N'',
@.delimiter=N',',
@.doNotRestate53WeekYear=N'0'
There were 10975 reads, 0 writes, and it took 1001 milliseconds

This is the query ran by the report server:
exec SalesByDivision
@.beginDate=''2006-12-31 00:00:00:000'',
@.endDate=''2007-02-03 00:00:00:000'',
@.lyBeginDate=''2006-01-01 00:00:00:000'',
@.lyEndDate=''2006-01-28 00:00:00:000'',
@.storesListName=N'Comp stores',
@.departmentsListName=N'Owned merchandise',
@.storesCustomList=N'',
@.departmentsCustomList=N'',
@.delimiter=N',',
@.doNotRestate53WeekYear=N'0'
There were 601409 reads, 0 writes, and it took 15326 milliseconds

|||

Did you try to just copy the exact text from the profiler? (to ensure that typo's and oversights aren't an issue)

Also, is the amount of system resources available possibly an issue?
Meaning, when running with just SQL MS, you are just using sql, but when you introduce RS, that's another program eating resources as well.

|||I notice you're not specifying a schema in your call to the stored procedure; do you have multiple versions of the SalesByDivision proc? If so, it might be defaulting to the one you want when you're connected in SQL Management Studio and an older or incorrect version when run under the context of the reporting services report. If not, I would trace the individual SQL statements as already mentioned and look for the statement(s) with highest reads to tune.|||

Thanks for the questions.

Yes, I copied the SQL from profiler then ran that in SQL MS.

These results are from a new production box. The system is consistently under load. Most reports that users are running are for very small date ranges and return within an acceptable time. However, reports with longer date ranges (the ones that managers and execs often run) are noticeby slower. Whether I run the SP from SQL MS or if I run a report, I assume the same resources are being used by RS.

|||There is only one version of the stored proc. For kicks I tried updating a report to include dbo. in front of the SP name. There was no noticable difference in load time.|||but add in t-sql commands to your trace. Do you know how to do this?|||

WITH RECOMPILE

Another one of our developers found a forum where someone had posted the same issue. Their suggestion was to add WITH RECOMPILE to our stored proc. After doing this we have experienced dramatic increases in performance with no unexplained slow periods. Also, before we added WITHRECOMPILE, the processing would occasionally be unevenly distributed between the eight CPUs on the SQL Server. One of the eight would get pegged while the otheres were not. After making the change we have seen an even distribution among all CPUs. Now it's taking the same amount of time to retrieve the data from the report - around 13 seconds.

|||Thanks for getting back with the solution buckenn. This was really helpful.|||

This is FANTASTIC!!

I was experiencing the same problem - the stored proc would run quickly, however, the report would take up to 15 minutes - and there wasn't much data being returned - fewer than 30 rows and only 15 columns. After adding WITH RECOMPILE to the proc, now the report generates in 15 seconds.

Data retrieval is much slower in RS than in management studio

A call to a stored procedure completes in 13 seconds when ran from within SQL Server Management Studio. A report whose data source uses the same stored procedure can take as long as 10 minutes to run. The same parameter values are used in both the direct call and the report. The execution log says almost all of that time is spent on data retrieval. How could that be? What might be the cause?If you didn't already, try profiling your sql instance right before you run your report. Have tsql statements shown so you can see a better breakdown of each command executing. This might show that the parameters used for the report are actually different than what you're expecting.|||I'll give it a try. However, looking at the Parameters column from the ExecutionLog table confirms that the values are the same. The report has the same parameters as the stored proc and simply passes the its parameter values along to the stored proc.|||

I set up a trace, launced the report and ran the SP from with SQL MS, then stopped the trace when the report came back. Instead of requesting a whole year's worth of data (which can take over 10 minute), I used a month. It takes about 15 times longer to run the report via RS than it does from within SQL MS.

When ran via RS, there are over 50x the number of reads.

From trace log:
This is the query ran from within MS:
exec SalesByDivision
@.beginDate='2006-12-31 00:00:00:000',
@.endDate='2007-02-03 00:00:00:000',
@.lyBeginDate='2006-01-01 00:00:00:000',
@.lyEndDate='2006-01-28 00:00:00:000',
@.storesListName=N'Comp stores',
@.departmentsListName=N'Owned merchandise',
@.storesCustomList=N'',
@.departmentsCustomList=N'',
@.delimiter=N',',
@.doNotRestate53WeekYear=N'0'
There were 10975 reads, 0 writes, and it took 1001 milliseconds

This is the query ran by the report server:
exec SalesByDivision
@.beginDate=''2006-12-31 00:00:00:000'',
@.endDate=''2007-02-03 00:00:00:000'',
@.lyBeginDate=''2006-01-01 00:00:00:000'',
@.lyEndDate=''2006-01-28 00:00:00:000'',
@.storesListName=N'Comp stores',
@.departmentsListName=N'Owned merchandise',
@.storesCustomList=N'',
@.departmentsCustomList=N'',
@.delimiter=N',',
@.doNotRestate53WeekYear=N'0'
There were 601409 reads, 0 writes, and it took 15326 milliseconds

|||

Did you try to just copy the exact text from the profiler? (to ensure that typo's and oversights aren't an issue)

Also, is the amount of system resources available possibly an issue?
Meaning, when running with just SQL MS, you are just using sql, but when you introduce RS, that's another program eating resources as well.

|||I notice you're not specifying a schema in your call to the stored procedure; do you have multiple versions of the SalesByDivision proc? If so, it might be defaulting to the one you want when you're connected in SQL Management Studio and an older or incorrect version when run under the context of the reporting services report. If not, I would trace the individual SQL statements as already mentioned and look for the statement(s) with highest reads to tune.|||

Thanks for the questions.

Yes, I copied the SQL from profiler then ran that in SQL MS.

These results are from a new production box. The system is consistently under load. Most reports that users are running are for very small date ranges and return within an acceptable time. However, reports with longer date ranges (the ones that managers and execs often run) are noticeby slower. Whether I run the SP from SQL MS or if I run a report, I assume the same resources are being used by RS.

|||There is only one version of the stored proc. For kicks I tried updating a report to include dbo. in front of the SP name. There was no noticable difference in load time.|||but add in t-sql commands to your trace. Do you know how to do this?|||

WITH RECOMPILE

Another one of our developers found a forum where someone had posted the same issue. Their suggestion was to add WITH RECOMPILE to our stored proc. After doing this we have experienced dramatic increases in performance with no unexplained slow periods. Also, before we added WITH RECOMPILE, the processing would occasionally be unevenly distributed between the eight CPUs on the SQL Server. One of the eight would get pegged while the otheres were not. After making the change we have seen an even distribution among all CPUs. Now it's taking the same amount of time to retrieve the data from the report - around 13 seconds.

|||Thanks for getting back with the solution buckenn. This was really helpful.|||

This is FANTASTIC!!

I was experiencing the same problem - the stored proc would run quickly, however, the report would take up to 15 minutes - and there wasn't much data being returned - fewer than 30 rows and only 15 columns. After adding WITH RECOMPILE to the proc, now the report generates in 15 seconds.

Data regions are not allowed inside a table detail ..

Developing using Visual Studio .Net (2003).
I have a simple table on my report showing data from a dataset. Works
fine. Displays a bunch of records.
One of the values from my dataset is a percentage value (integer from 0
to 100). I'm attempting to illustrate this using a chart. So I'm
attempting to put a chart in the table detail row. It doesn't like me
doing this, though. I get a build error:
"The chart 'chartx' is contained inside a table detail row. Data
regions are not allowed inside a table detail...".
Is there a way to do what I'm attempting with Visual Studio .Net (i.e.
SQL Server 2000 Reporting Services)? I know it can be done with Visual
Studio 2005, as that just makes you define a group expression when
attempting to "use a data region in a list".
Any help/info would be great.
Thanks.Have you tried putting it inside a matrix?
I tried putting a chart inside a table detail row, but vs didn't let me
do it "Cannot place a chart at this location in a table"
However, putting it inside a matrix works just fine.
eamon wrote:
> Developing using Visual Studio .Net (2003).
> I have a simple table on my report showing data from a dataset. Works
> fine. Displays a bunch of records.
> One of the values from my dataset is a percentage value (integer from 0
> to 100). I'm attempting to illustrate this using a chart. So I'm
> attempting to put a chart in the table detail row. It doesn't like me
> doing this, though. I get a build error:
> "The chart 'chartx' is contained inside a table detail row. Data
> regions are not allowed inside a table detail...".
> Is there a way to do what I'm attempting with Visual Studio .Net (i.e.
> SQL Server 2000 Reporting Services)? I know it can be done with Visual
> Studio 2005, as that just makes you define a group expression when
> attempting to "use a data region in a list".
> Any help/info would be great.
> Thanks.sql

Data problem when publishing website

I published my website directly to its production folder then opened Sql Express Management Studio and attached the ASPNETDB file to it in that folder. However, the location information displayed in the Databases window shows the file is actually mapped back to my development folder. ?

Has anyone else encountered this problem?

Yes, I did verify that I selected the correct location.

Okay, my mistake, it isn't actually mapped back to that file, it just names the database with the original path. Gotta wonder what genius thought that one up.

Data not printing from crystal report generated using parameterized query in ASP

Data not printing from crystal report (9.0) generated using parameterized query in ASP.Net (Visual Studio 2003). But data is displaying properly. Tried changing the font to printer font, but no luck.
Any ideas?
Thanks,
Narayana Murty.Is there a problem in Printer settings?
Check the network

Data not being displayed.

Hi,
I have just installed MS SQL in my computer and I am trying to run MSSQL and Visual studio for the first time. However I have run into aproblem that I can't solve. Basically the problem is that the data Ifetch from the database is not being displayed/bound to the ddl I haveon the page.
I have used VS to configure the sqlDataAdapter, DataSet, sqlConnection,and the sqlCommands. Basically the data is being fetched from theNorthwind sample database. From the preview option on thesqlDataAdapter I am able to preview the information from the database.So it seems to work. I have also configured the ddl settings so thatthe Categories table is the datasource. I have also set the ddl.DataTextField = "CategoryName"; ddl.DataValueField = "CategoryID";
When I compiled and run the page, no error messages are generated, butthe ddl is still completely blank and I can't understand why.
Does anybody know how I can solve this?? :s

Om Sri Sai Ram

Did you callDataBind method.

Thanks,

Ram

|||Hi,
I have just double-checked that I had called DataBind, and itturns out that I had. However, I had forgotten to fill the DataSet:
this.sqlDataAdapter1.Fill(this.dataSet11);
Now I get an error message:
Login failed for user 'DISABLED\ASPNET'|||Om Sri Sai Ram

Are u using windows authentication? If yes, check whether ASPNET account has pemission to access the table.
If you still have problems, post the code.
Thanks,
Ram

Data Mining Tool

I am new to Data Mining

I downloaded the SQL SERVER 2005 Evaluation Edition.

Question:

For Data Mining which Product Edition of VISUAL STUDIO 2005 i have to download ? ,

You don't need to download/install Visual Studio 2005 separately to use the SQL Server 2005 tools. SQL Server 2005 Setup should install the VS shell components that are used by the design and management tools. Data Mining is available in the Developer, Standard and Enterprise Editions of SQL Server 2005 (the Evaluation version is Enterprise).|||

Hi Raman

WIthin Your Technet webcast 'Intro. to DM with SS2005' you used 'Visual Studio Team' to build the Data Mining demo.

Thats the reason i raised the question.

Your webcast is excellet.

Keep doing more webcase on the DATA MINING.

Thank you very much for your reply.

Rgs - Antony Kumar

|||

Thanks for the feedback, Antony.

The SQL Server design/mgmt tools are hosted in the Visual Studio 2005 shell. If you don't have Visual Studio 2005 installed, SQL Setup installs the base shell components needed. In either case, the user interface that comes up when you open up Business Intelligence Development Studio is the Visual Studio UI. (I just happened to have the full Visual Studio installed on the machine on which I showed the demo in my webcast.)

|||

Hi,

Where can I watch the 'Intro. to DM with SS20" webcast ?

Thanks,

ST

|||

You can find this webcast on-demand here: http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032289986&EventCategory=5&culture=en-US&CountryCode=US

There's also another live version of this webcast coming up on May 12, where you'll be able to ask questions via LiveMeeting:

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032294887&EventCategory=5&culture=en-US&CountryCode=US

Data Link properties don't show any istance

Hi
Data Link Properties, open by test.udl file, when open don't show any
istance of MSDE sp3 installed.
By Visual Studio.NET 2003 Server Manager I can see the server and database.
If I insert manually name istance and try test connect it return me this
message:
Test connection failed because of an error initializing provider.
[DBNETLIB][ConnectionOpen(Connect()).]SQL Server does not exist or access
denied.
My system is:
Windows XP pro
Visual Studio.NET 2003
MSDE sp3
MDAC 2.8
Can you help me?
I answered your later post, regarding the same issue.
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
"Giuseppe Pezzella" <gpezzella@.yahoo.com> wrote in message
news:su31d.307127$5D1.13632538@.news4.tin.it...
> Hi
> Data Link Properties, open by test.udl file, when open don't show any
> istance of MSDE sp3 installed.
> By Visual Studio.NET 2003 Server Manager I can see the server and
database.
> If I insert manually name istance and try test connect it return me this
> message:
> Test connection failed because of an error initializing provider.
> [DBNETLIB][ConnectionOpen(Connect()).]SQL Server does not exist or access
> denied.
>
> My system is:
> Windows XP pro
> Visual Studio.NET 2003
> MSDE sp3
> MDAC 2.8
> Can you help me?
>

Data in Table not showing

I am just starting with Report Services, so this may be an easy or dumb
problem but here goes:
I am working in Visual Studio with a simple report based on a sproc with
several parameters that returns a result set. In the report I have set up a
table and the dataset for it, as well as the parameters. Everything works
great until I test the report, the report renders but the table shows as
having no data. I can go to the data tab and run the sproc and enter the
same parameters and I get data back.
I have checked all the places I could think of that might hide the data, but
nothing.
I'm hoping someone else has been through this or has some ideas on where I
could look.
TIA,
NancyHave you added a filter somewhere? Edit the dataset on the Data tab, click
the Filters tab and see. Also go to Properties of your table and check the
Filters tab. If your sproc returns data, the data should appear in the
report. I have a sproc in one of my reports and ti works just fine.
Charles Kangai, MCT, MCDBA
"Nancy Lytle" wrote:
> I am just starting with Report Services, so this may be an easy or dumb
> problem but here goes:
> I am working in Visual Studio with a simple report based on a sproc with
> several parameters that returns a result set. In the report I have set up a
> table and the dataset for it, as well as the parameters. Everything works
> great until I test the report, the report renders but the table shows as
> having no data. I can go to the data tab and run the sproc and enter the
> same parameters and I get data back.
> I have checked all the places I could think of that might hide the data, but
> nothing.
> I'm hoping someone else has been through this or has some ideas on where I
> could look.
> TIA,
> Nancy
>
>|||Thanks, I went ahead and I checked for filters and I can find none. I know
it must be something simple I am missing.
Any other ideas? Anyone?
TIA,
Nancy
"Charles Kangai" <CharlesKangai@.discussions.microsoft.com> wrote in message
news:53541C34-C4A7-4769-AB92-43C023605AFD@.microsoft.com...
> Have you added a filter somewhere? Edit the dataset on the Data tab, click
> the Filters tab and see. Also go to Properties of your table and check the
> Filters tab. If your sproc returns data, the data should appear in the
> report. I have a sproc in one of my reports and ti works just fine.
> Charles Kangai, MCT, MCDBA
> "Nancy Lytle" wrote:
> > I am just starting with Report Services, so this may be an easy or dumb
> > problem but here goes:
> >
> > I am working in Visual Studio with a simple report based on a sproc with
> > several parameters that returns a result set. In the report I have set
up a
> > table and the dataset for it, as well as the parameters. Everything
works
> > great until I test the report, the report renders but the table shows as
> > having no data. I can go to the data tab and run the sproc and enter
the
> > same parameters and I get data back.
> > I have checked all the places I could think of that might hide the data,
but
> > nothing.
> >
> > I'm hoping someone else has been through this or has some ideas on where
I
> > could look.
> > TIA,
> > Nancy
> >
> >
> >

data import sql server management studio

I went through the data import wizard and it successfully
went through all the procedures to import data from an
access table into an sql server table, however, there is no
data in the table?
What could I be missing?
Thanks
For troubleshooting, I'd try to import from a different source (perhaps a
different Access database or even a flat file) to make sure there is nothing
wrong with the import wizard, the drivers, or the steps.
Linchi
"segue" wrote:

> I went through the data import wizard and it successfully
> went through all the procedures to import data from an
> access table into an sql server table, however, there is no
> data in the table?
> What could I be missing?
> Thanks

data import sql server management studio

I went through the data import wizard and it successfully
went through all the procedures to import data from an
access table into an sql server table, however, there is no
data in the table?
What could I be missing?
ThanksFor troubleshooting, I'd try to import from a different source (perhaps a
different Access database or even a flat file) to make sure there is nothing
wrong with the import wizard, the drivers, or the steps.
Linchi
"segue" wrote:
> I went through the data import wizard and it successfully
> went through all the procedures to import data from an
> access table into an sql server table, however, there is no
> data in the table?
> What could I be missing?
> Thanks