Showing posts with label empty. Show all posts
Showing posts with label empty. Show all posts

Tuesday, March 20, 2012

Big queries return empty result set

Hello guys,

MS SQL server 2000 behavies strange with big queries that involves relatively large number of tables:
If I just enumerate columns I want to receive, the result set is empty. Adding * to the column list without making any change to where clause seems to solve the problem but I guess it's not the best practice.
The most amazing is that this behavior is not stable, so I suppose there's something to deal with server itself, not the application.
Has anybody suffered this problem and what solution was adopted?
Thanks for any information you can provide.Most of my queries are small (less than 200 columns and 500,000 rows), so maybe I'm not hitting the kind of volume that you are, but I've never heard of that behavior! I also rarely push beyond 30-50 tables in a single query with the exception of one purchased package that sometimes can create monsters.

Can you give me a rough idea of how big your database is (in gigabytes) and how big your result set is (rows, columns, and megabytes)? I'll try to reproduce the behavior here with a known good server.

-PatP|||Definitely my queries never get this volume. I have a join of about 15 tables with 10 columns in each. Empty recordset is an ocasional behavior, i mean today the query may work perfectly, tomorrow absolutely exact query with absolutely exact parameters without any modification made to the database fails.
I was told that this could be caused by particular, localized version of SQL server that we use (sql server 2000 SP3 spanish, 8.00.760). Could you confirm that?

Originally posted by Pat Phelan
Most of my queries are small (less than 200 columns and 500,000 rows), so maybe I'm not hitting the kind of volume that you are, but I've never heard of that behavior! I also rarely push beyond 30-50 tables in a single query with the exception of one purchased package that sometimes can create monsters.

Can you give me a rough idea of how big your database is (in gigabytes) and how big your result set is (rows, columns, and megabytes)? I'll try to reproduce the behavior here with a known good server.

-PatP|||Originally posted by Pat Phelan
Most of my queries are small (less than 200 columns and 500,000 rows), so maybe I'm not hitting the kind of volume that you are, but I've never heard of that behavior! I also rarely push beyond 30-50 tables in a single query with the exception of one purchased package that sometimes can create monsters.


:D

Why not POST the query...|||Originally posted by Brett Kaiser
:D

Why not POST the query...

As you wish:
--NON-EMPTY RESULTSET--

select bb.i_object_id as bb_aa, bb.i_object_type_id as bb_ab,
<skipped about 50 columns>
bl.i_operation_id as bl_ak, bl.integra_operation_id as bl_al,
* <-- this allows me receive data
from i_sysobject bb, part_list_item bc,
i_relation bd,
i_sysobject be, part_list bf,
i_relation bg, i_sysobject bh,
production_order bi, i_relation bj,
i_sysobject bk, operation bl
where bc.i_part_list_item_id = bb.i_object_id and
bf.state = ? and
bf.i_part_list_id = be.i_object_id and
bi.i_production_order_id = bh.i_object_id and
bl.i_operation_id = bk.i_object_id and
bc.i_part_list_item_id=bd.i_relation_child_object_ id and
bd.i_relation_parent_object_id=bf.i_part_list_id and
bf.i_part_list_id=bg.i_relation_child_object_id and
bg.i_relation_parent_object_id=bi.i_production_ord er_id and
bf.i_part_list_id=bj.i_relation_child_object_id and
bj.i_relation_parent_object_id=bl.i_operation_id
order by bf.i_part_list_id asc

--EMPTY RESULTSET--
select bb.i_object_id as bb_aa, bb.i_object_type_id as bb_ab,
<skipped about 50 columns>
bl.i_operation_id as bl_ak, bl.integra_operation_id as bl_al
from i_sysobject bb, part_list_item bc,
i_relation bd,
i_sysobject be, part_list bf,
i_relation bg, i_sysobject bh,
production_order bi, i_relation bj,
i_sysobject bk, operation bl
where bc.i_part_list_item_id = bb.i_object_id and
bf.state = ? and
bf.i_part_list_id = be.i_object_id and
bi.i_production_order_id = bh.i_object_id and
bl.i_operation_id = bk.i_object_id and
bc.i_part_list_item_id=bd.i_relation_child_object_ id and
bd.i_relation_parent_object_id=bf.i_part_list_id and
bf.i_part_list_id=bg.i_relation_child_object_id and
bg.i_relation_parent_object_id=bi.i_production_ord er_id and
bf.i_part_list_id=bj.i_relation_child_object_id and
bj.i_relation_parent_object_id=bl.i_operation_id
order by bf.i_part_list_id asc

bf.state = ? receives the SAME parameter in both cases.|||Everything is identity, isn't it...

Is one of these tables a driver? Like what you want to base your result set on?

Lots of sele referencing...

Maybe you can use derived tables..

SELECT * FROM (SELECT * FROM ...join the table that relate) AS A
LEFT JOIN (SELECT * FROM ..same thing) AS B
ON A.key = B.Key

Here's your code cleaned up some..Not sure if it's doing the same thing...

I think it is...and easier to see what you're trying to do

SELECT *
FROM i_sysobject bb
LEFT JOIN part_list_item bc ON bc.i_part_list_item_id = bb.i_object_id
LEFT JOIN i_relation bd ON bc.i_part_list_item_id=bd.i_relation_child_object_ id
LEFT JOIN i_sysobject be ON bf.i_part_list_id = be.i_object_id and
LEFT JOIN part_list bf ON bd.i_relation_parent_object_id=bf.i_part_list_id
LEFT JOIN i_relation bg ON bf.i_part_list_id=bg.i_relation_child_object_id
LEFT JOIN i_sysobject bh ON bi.i_production_order_id = bh.i_object_id
LEFT JOIN production_order bi ON bg.i_relation_parent_object_id=bi.i_production_ord er_id
LEFT JOIN i_relation bj ON bf.i_part_list_id=bj.i_relation_child_object_id
LEFT JOIN i_sysobject bk ON bl.i_operation_id = bk.i_object_id
LEFT JOIN operation bl ON bj.i_relation_parent_object_id=bl.i_operation_id
WHERE bf.state = ?

Friday, February 24, 2012

Best Way to transfer a table

What is the best way to send someone a table - Complete definition and data.
I have tried creating a new empty database and just add the one table and
back that up but it is a huge file. I tried exporting the rows to Excel but
that will only allow 65K rows. I was surprised to see not option for xml in
E.M.
thanks,
GMS Access? FoxPro? There are dozens of ways to _send_ the data.
However, no matter what you do, unless you send the end user an MSSQL DDL
Script, they'll never really know just _exactly_ how it was in SQL Server.
Why not just send a DDL script and a fixed-width text file?
James Hokes
"Gary" <gb@.nospam.com> wrote in message
news:epSLJt0xDHA.1764@.TK2MSFTNGP10.phx.gbl...
> What is the best way to send someone a table - Complete definition and
data.
> I have tried creating a new empty database and just add the one table and
> back that up but it is a huge file. I tried exporting the rows to Excel
but
> that will only allow 65K rows. I was surprised to see not option for xml
in
> E.M.
> thanks,
> G
>|||My opinion is that the data should be sent in TDF (tab
delimited) format. Comma-separated is no good - since so
much data can have commas.
TDF's BULK INSERT perfectly.
In query analyzer, do a SELECT * From table and in the
RESULT GRID - select all / copy&paste into NOTEPAD.
This gives you the TDF data in a text file.
If you were to BULK INSERT this back into the table it
would be identical.
We have two little VB programs here called TextImport and
TextOutput that we use constantly. Part of
our "distribute" table data to a customer and back from a
customer. We use these because copy/paste and notepad do
have limitations on width that we have encountered...
>--Original Message--
>MS Access? FoxPro? There are dozens of ways to _send_
the data.
>However, no matter what you do, unless you send the end
user an MSSQL DDL
>Script, they'll never really know just _exactly_ how it
was in SQL Server.
>Why not just send a DDL script and a fixed-width text
file?
>James Hokes
>"Gary" <gb@.nospam.com> wrote in message
>news:epSLJt0xDHA.1764@.TK2MSFTNGP10.phx.gbl...
>> What is the best way to send someone a table -
Complete definition and
>data.
>> I have tried creating a new empty database and just
add the one table and
>> back that up but it is a huge file. I tried exporting
the rows to Excel
>but
>> that will only allow 65K rows. I was surprised to see
not option for xml
>in
>> E.M.
>> thanks,
>> G
>>
>
>.
>|||Even Tab is not bullet-proof.
Tab is ASCII character 9. Plenty of tabs in varchar fields, I assure you.
I'll send you a file that'll break your app right now if you like.
The only bullet-proof text file is a fixed-width one.
Absolutely bullet-proof.
Ask any mainframe DBA.
James Hokes
"Steve z" <szlamany@.antarescomputing.com> wrote in message
news:018701c3c75e$fca3c3b0$a601280a@.phx.gbl...
> My opinion is that the data should be sent in TDF (tab
> delimited) format. Comma-separated is no good - since so
> much data can have commas.
> TDF's BULK INSERT perfectly.
> In query analyzer, do a SELECT * From table and in the
> RESULT GRID - select all / copy&paste into NOTEPAD.
> This gives you the TDF data in a text file.
> If you were to BULK INSERT this back into the table it
> would be identical.
> We have two little VB programs here called TextImport and
> TextOutput that we use constantly. Part of
> our "distribute" table data to a customer and back from a
> customer. We use these because copy/paste and notepad do
> have limitations on width that we have encountered...
>
> >--Original Message--
> >MS Access? FoxPro? There are dozens of ways to _send_
> the data.
> >
> >However, no matter what you do, unless you send the end
> user an MSSQL DDL
> >Script, they'll never really know just _exactly_ how it
> was in SQL Server.
> >
> >Why not just send a DDL script and a fixed-width text
> file?
> >
> >James Hokes
> >
> >"Gary" <gb@.nospam.com> wrote in message
> >news:epSLJt0xDHA.1764@.TK2MSFTNGP10.phx.gbl...
> >> What is the best way to send someone a table -
> Complete definition and
> >data.
> >> I have tried creating a new empty database and just
> add the one table and
> >> back that up but it is a huge file. I tried exporting
> the rows to Excel
> >but
> >> that will only allow 65K rows. I was surprised to see
> not option for xml
> >in
> >> E.M.
> >> thanks,
> >> G
> >>
> >>
> >
> >
> >.
> >|||Actually if this is going to another SQL Server I would use the native
format of BCP instead of text.
--
Andrew J. Kelly SQL MVP
"James Hokes" <noemail@.noway.com> wrote in message
news:eiwloA3xDHA.2396@.TK2MSFTNGP09.phx.gbl...
> Even Tab is not bullet-proof.
> Tab is ASCII character 9. Plenty of tabs in varchar fields, I assure you.
> I'll send you a file that'll break your app right now if you like.
> The only bullet-proof text file is a fixed-width one.
> Absolutely bullet-proof.
> Ask any mainframe DBA.
> James Hokes
> "Steve z" <szlamany@.antarescomputing.com> wrote in message
> news:018701c3c75e$fca3c3b0$a601280a@.phx.gbl...
> > My opinion is that the data should be sent in TDF (tab
> > delimited) format. Comma-separated is no good - since so
> > much data can have commas.
> >
> > TDF's BULK INSERT perfectly.
> >
> > In query analyzer, do a SELECT * From table and in the
> > RESULT GRID - select all / copy&paste into NOTEPAD.
> >
> > This gives you the TDF data in a text file.
> >
> > If you were to BULK INSERT this back into the table it
> > would be identical.
> >
> > We have two little VB programs here called TextImport and
> > TextOutput that we use constantly. Part of
> > our "distribute" table data to a customer and back from a
> > customer. We use these because copy/paste and notepad do
> > have limitations on width that we have encountered...
> >
> >
> > >--Original Message--
> > >MS Access? FoxPro? There are dozens of ways to _send_
> > the data.
> > >
> > >However, no matter what you do, unless you send the end
> > user an MSSQL DDL
> > >Script, they'll never really know just _exactly_ how it
> > was in SQL Server.
> > >
> > >Why not just send a DDL script and a fixed-width text
> > file?
> > >
> > >James Hokes
> > >
> > >"Gary" <gb@.nospam.com> wrote in message
> > >news:epSLJt0xDHA.1764@.TK2MSFTNGP10.phx.gbl...
> > >> What is the best way to send someone a table -
> > Complete definition and
> > >data.
> > >> I have tried creating a new empty database and just
> > add the one table and
> > >> back that up but it is a huge file. I tried exporting
> > the rows to Excel
> > >but
> > >> that will only allow 65K rows. I was surprised to see
> > not option for xml
> > >in
> > >> E.M.
> > >> thanks,
> > >> G
> > >>
> > >>
> > >
> > >
> > >.
> > >
>|||Been a VAX mainframe programmer since late 70's - used
fixed width for 20+ years on the mainframe. Lots of
effort in mapping data - input and output sides - lots of
room for bugs (we always consider the maintenance
nightmare).
We happen to be very familiar with our data - no tabs
anywhere - and we have medical claim tables with 2.5
million rows... (program checks for tab in data anyway -
simple to do)
What we like about our method is that our VB textoutput
program puts dates in a nice format so that BULK INSERT
works without issue. But as an app development shop, we
only support a handful of datatypes - we like the variety
that SQL has, but no reason to beat up the programmers
with each ones quirks...
Our textoutput program also uses an .INI file to specify
server/database/table and even a SELECT statement if you
want to override the defaults of SELECT *. We actually
use it inside the SQL Agent to run nightly jobs that push
text files back to the legacy VAX's at several sites.
The VAX-11 BASIC programs on the mainframe only have to
cutup the input lines by looking for TAB's - so column
issues are the only ones to consider - no mapping of
specific byte positions.
We even have mainframe programs that analyze the legacy
database structures and create .SQL scripts to "CREATE
TABLE's" and text files for BULK INSERT's. We even
include the BULK INSERT statement (with proper server
path to text file) in the .SQL script created on the
mainframe.
We can take a mainframe's application data and get it
into SQL in short order with these tools.
>--Original Message--
>Even Tab is not bullet-proof.
>Tab is ASCII character 9. Plenty of tabs in varchar
fields, I assure you.
>I'll send you a file that'll break your app right now if
you like.
>The only bullet-proof text file is a fixed-width one.
>Absolutely bullet-proof.
>Ask any mainframe DBA.
>James Hokes
>"Steve z" <szlamany@.antarescomputing.com> wrote in
message
>news:018701c3c75e$fca3c3b0$a601280a@.phx.gbl...
>> My opinion is that the data should be sent in TDF (tab
>> delimited) format. Comma-separated is no good - since
so
>> much data can have commas.
>> TDF's BULK INSERT perfectly.
>> In query analyzer, do a SELECT * From table and in the
>> RESULT GRID - select all / copy&paste into NOTEPAD.
>> This gives you the TDF data in a text file.
>> If you were to BULK INSERT this back into the table it
>> would be identical.
>> We have two little VB programs here called TextImport
and
>> TextOutput that we use constantly. Part of
>> our "distribute" table data to a customer and back
from a
>> customer. We use these because copy/paste and notepad
do
>> have limitations on width that we have encountered...
>>
>> >--Original Message--
>> >MS Access? FoxPro? There are dozens of ways to _send_
>> the data.
>> >
>> >However, no matter what you do, unless you send the
end
>> user an MSSQL DDL
>> >Script, they'll never really know just _exactly_ how
it
>> was in SQL Server.
>> >
>> >Why not just send a DDL script and a fixed-width text
>> file?
>> >
>> >James Hokes
>> >
>> >"Gary" <gb@.nospam.com> wrote in message
>> >news:epSLJt0xDHA.1764@.TK2MSFTNGP10.phx.gbl...
>> >> What is the best way to send someone a table -
>> Complete definition and
>> >data.
>> >> I have tried creating a new empty database and just
>> add the one table and
>> >> back that up but it is a huge file. I tried
exporting
>> the rows to Excel
>> >but
>> >> that will only allow 65K rows. I was surprised to
see
>> not option for xml
>> >in
>> >> E.M.
>> >> thanks,
>> >> G
>> >>
>> >>
>> >
>> >
>> >.
>> >
>
>.
>

Sunday, February 12, 2012

Best Way to Empty Transaction Log

Hi All,
What is a best way to empty (shrink) a database transaction log. I am
working with huge database - 10GB to 100GB- and basically doesn't care
about transaction log much when data is being deleted by a task. I have a
deletion task consisted of many stored procedures which is running every
night. In some of the client's database, when those stored procedure
deleted data in different tables, the transaction log getting to big and SQL
appears to hang up. Sometimes a deletion task will take a whole weekend.
Note that the stored procedures do use TRUNCATE TRANSACTION and CHECK POINT
trying to reduce the size of the transaction log.
My question is, how can I tell SQL not to log the transactions when my
deletion procedures are running. If there is no way to to tell SQL not to
log the transactions, is the a better way to control the size of the
transaction log file, other than using the CHECK POINT?
Thanks.A CHECKPOINT followed by a DBCC SHRINKFILE, works for us. We shrink our log
before backup everynight, the log itself will hit 100GB(400GB+ DB) over
weekend maintenace. Shrinkfile usually goes quick on the log.
" David N" <dq.ninh@.netiq.com> wrote in message
news:en54Y$qWDHA.2328@.TK2MSFTNGP12.phx.gbl...
> Hi All,
> What is a best way to empty (shrink) a database transaction log. I am
> working with huge database - 10GB to 100GB- and basically doesn't care
> about transaction log much when data is being deleted by a task. I have a
> deletion task consisted of many stored procedures which is running every
> night. In some of the client's database, when those stored procedure
> deleted data in different tables, the transaction log getting to big and
SQL
> appears to hang up. Sometimes a deletion task will take a whole weekend.
> Note that the stored procedures do use TRUNCATE TRANSACTION and CHECK
POINT
> trying to reduce the size of the transaction log.
> My question is, how can I tell SQL not to log the transactions when my
> deletion procedures are running. If there is no way to to tell SQL not to
> log the transactions, is the a better way to control the size of the
> transaction log file, other than using the CHECK POINT?
> Thanks.
>|||Did not read well, sry. All your DELETE FROMs are going to be logged, that
is a good thing. If you are clearing out the entire table, you can use the
TRUNCATE TABLE which is non-logged. If you cannot use TRUNCATE TABLE and
must use DELETE FROM, you can try an optimize it to run more efficiently.
The DELETE might run quicker if you can base the delete off the CLUSTERED
INDEX(use temp tables if needed to achieve) or if this table is index heavy
you might drop some indexes(non-clustered only) and recreate them when the
delete process is finished.
My personal way if it is large delete filling up your log(ie one big logged
transaction). I would suck all the CLUSTERED INDEX values into a temp table
and use a WHILE with TOP functionality in it to loop the delete in smaller
digestible chunks. This will allow the log backups to clear out the
transaction log(make sure these are running in good intervals, ours go every
5mins). We have even added functionality to some of our bigger maint procs
to check logsize during loops and run a log backup to keep it in check.
HTH.
"Kevin Brooks" <kbrooks@.sagetelecom.net> wrote in message
news:OsdM$DrWDHA.2032@.TK2MSFTNGP11.phx.gbl...
> A CHECKPOINT followed by a DBCC SHRINKFILE, works for us. We shrink our
log
> before backup everynight, the log itself will hit 100GB(400GB+ DB) over
> weekend maintenace. Shrinkfile usually goes quick on the log.
>
> " David N" <dq.ninh@.netiq.com> wrote in message
> news:en54Y$qWDHA.2328@.TK2MSFTNGP12.phx.gbl...
> > Hi All,
> >
> > What is a best way to empty (shrink) a database transaction log. I am
> > working with huge database - 10GB to 100GB- and basically doesn't care
> > about transaction log much when data is being deleted by a task. I have
a
> > deletion task consisted of many stored procedures which is running every
> > night. In some of the client's database, when those stored procedure
> > deleted data in different tables, the transaction log getting to big and
> SQL
> > appears to hang up. Sometimes a deletion task will take a whole
weekend.
> > Note that the stored procedures do use TRUNCATE TRANSACTION and CHECK
> POINT
> > trying to reduce the size of the transaction log.
> >
> > My question is, how can I tell SQL not to log the transactions when my
> > deletion procedures are running. If there is no way to to tell SQL not
to
> > log the transactions, is the a better way to control the size of the
> > transaction log file, other than using the CHECK POINT?
> >
> > Thanks.
> >
> >
>

Best way to create SQL2005 DB from VB.Net

I have written a VB.Net (2005) program to load an empty SQL Server 2005
database from another data source. At the moment I create the empty SQL
database by manually running a DDL script in SQL Server Management Studio.
However, I need to modify the VB.Net program so that the database is created
programmatically before beginning the load process. My question is how best
to do this?
I know I can do this by cutting and pasting the DDL into Visual Studio and
converting it into a string. But this is an onerous task, and as the DDL is
still evolving I do not consider this an option.
Another option is to open the DDL file, read it into a string, and then
execute it. Has anyone done this? One divantage of this option is that I
need to ship the DDL as a separate file with my app and this leaves it open
to modification by the user.
If there is another way I haven’t come across I would greatly appreciate a
few pointers.You can create a vb application that accepts the user inputs like database
name, server name and other parameters and use SQL-DMO to creae the database
.
You can check this link for the code...
http://groups.google.co.in/group/mi...7dfc44c4bf8e926
and this link for the interface...
http://www.codeproject.com/useritems/SQLDBBackup.asp
Hope this was what you wanted.
"David" wrote:

> I have written a VB.Net (2005) program to load an empty SQL Server 2005
> database from another data source. At the moment I create the empty SQL
> database by manually running a DDL script in SQL Server Management Studio.
> However, I need to modify the VB.Net program so that the database is creat
ed
> programmatically before beginning the load process. My question is how bes
t
> to do this?
> I know I can do this by cutting and pasting the DDL into Visual Studio and
> converting it into a string. But this is an onerous task, and as the DDL i
s
> still evolving I do not consider this an option.
> Another option is to open the DDL file, read it into a string, and then
> execute it. Has anyone done this? One divantage of this option is that
I
> need to ship the DDL as a separate file with my app and this leaves it ope
n
> to modification by the user.
> If there is another way I haven’t come across I would greatly appreciate
a
> few pointers.
>|||I had a look at SQL-DMO in the SQL Server Books Online and quickly discovere
d
it has been superseded by SQL-SMO (SQL-DMO is a COM object, whereas SMO is
implemented as a .NET assembly).
Since I'm using VS2005 I'll look into SMO and will see how I go.
"Omnibuzz" wrote:
> You can create a vb application that accepts the user inputs like database
> name, server name and other parameters and use SQL-DMO to creae the databa
se.
> You can check this link for the code...
> http://groups.google.co.in/group/mi...7dfc44c4bf8e926
> and this link for the interface...
> http://www.codeproject.com/useritems/SQLDBBackup.asp
> Hope this was what you wanted.
>
> "David" wrote:
>|||Thats right. But implemetation in SMO hasn't got much documentation yet. I
had been trying to get it and didn't get much help.
Thats why suggested DMo. I apologise if I misled you :)
--
"David" wrote:
> I had a look at SQL-DMO in the SQL Server Books Online and quickly discove
red
> it has been superseded by SQL-SMO (SQL-DMO is a COM object, whereas SMO is
> implemented as a .NET assembly).
> Since I'm using VS2005 I'll look into SMO and will see how I go.
> "Omnibuzz" wrote:
>|||I have been experimenting with SMO, and while I can get it to create
databases, tables, etc, I can't work out how to submit a script file for
execution. Do you know how this is done in SQL_DMO (there is a good cross
reference in the docs)?
P.S. In my case I have to use a script file as the DB design is done in
Visio and the script is generated for me. To convert this to command using
the SMO objects would take forever, and I would have to duplicate changes
made in the Visio diagram.
"Omnibuzz" wrote:
> Thats right. But implemetation in SMO hasn't got much documentation yet. I
> had been trying to get it and didn't get much help.
> Thats why suggested DMo. I apologise if I misled you :)
> --
>
>
> "David" wrote:
>|||try ExecuteImmediate and the ExecuteWithResults methods in the dmo for
executing scripts..
Is this the one you are looking for'
--
"David" wrote:
> I have been experimenting with SMO, and while I can get it to create
> databases, tables, etc, I can't work out how to submit a script file for
> execution. Do you know how this is done in SQL_DMO (there is a good cross
> reference in the docs)?
> P.S. In my case I have to use a script file as the DB design is done in
> Visio and the script is generated for me. To convert this to command using
> the SMO objects would take forever, and I would have to duplicate changes
> made in the Visio diagram.
> "Omnibuzz" wrote:
>|||Did you try, for instance Database.ExecuteNonQuery or Database.ExecuteWithRe
sults?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"David" <David@.discussions.microsoft.com> wrote in message
news:17A1C906-2BF4-4662-8ADC-6FA34C673214@.microsoft.com...
>I have been experimenting with SMO, and while I can get it to create
> databases, tables, etc, I can't work out how to submit a script file for
> execution. Do you know how this is done in SQL_DMO (there is a good cross
> reference in the docs)?
> P.S. In my case I have to use a script file as the DB design is done in
> Visio and the script is generated for me. To convert this to command using
> the SMO objects would take forever, and I would have to duplicate changes
> made in the Visio diagram.
> "Omnibuzz" wrote:
>|||Many thanks to you both (Ominbuzz and Tibor). Databases.ExecuteNonQuery work
s
like a charm.
The only thing I need to do now is work out how to get the script text file
into the compiled exe so that I don't have to deploy it and users can't
change it. But that would probably be better posted in the Vb.Net newsgroup.
"Tibor Karaszi" wrote:

> Did you try, for instance Database.ExecuteNonQuery or Database.ExecuteWith
Results?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "David" <David@.discussions.microsoft.com> wrote in message
> news:17A1C906-2BF4-4662-8ADC-6FA34C673214@.microsoft.com...
>
>|||Perhaps you can zip (or similar) it with a password and/or encryption and ha
ve your code unzip it.
I'm not .NET expert, though, so there are probably much neater ways of doing
this...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"David" <David@.discussions.microsoft.com> wrote in message
news:51F43AB1-FE3A-440E-BF67-F9A9859C80AE@.microsoft.com...
> Many thanks to you both (Ominbuzz and Tibor). Databases.ExecuteNonQuery wo
rks
> like a charm.
> The only thing I need to do now is work out how to get the script text fil
e
> into the compiled exe so that I don't have to deploy it and users can't
> change it. But that would probably be better posted in the Vb.Net newsgrou
p.
> "Tibor Karaszi" wrote:
>|||or you can just add the script as a string or a file your project resources.
http://msdn2.microsoft.com/en-us/li...resourcemanager(VS
.80).aspx
-oj