primary keys have gotten out of sequence

In Enterprise Manager, my primary keys used to be all in sequence. After de
leting a few pk and adding new ones, they are no longer in sequence.
In Enterprise Manager, I would like to be able to view "Return all rows" wit
h the primary keys in numerical order.
What is the best way to accomplish this?
Thank you in advance,
TRTimothy Ross wrote:
> In Enterprise Manager, my primary keys used to be all in sequence. After
deleting a few pk and adding new ones, they are no longer in sequence.
> In Enterprise Manager, I would like to be able to view "Return all rows" w
ith the primary keys in numerical order.
> What is the best way to accomplish this?
> Thank you in advance,
> TR
Tables have no inherent order. The only way to fix the order you see is
to use an ORDER BY clause in your SELECT statements. Enterprise Manager
won't do that for you - you need to write your own query. Preferably
use Query Analyzer instead because it's a much more powerful tool.
You'll need to familiarize yourself with SQL syntax first but that's
not so hard for the basic stuff. For example:
SELECT col1, col2, col3, ...
FROM your_table
ORDER BY col1 ;
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||David - Thank you for your quick response.
I understand that I can use query analyzer for sorting. I have actually
used Microsoft Access because this will allow sorting very easily.
I also understand that the primary keys really do not need to be displayed
in any particular order.
I have been told there is a command that will re-order my primary keys
sequentially so that I can view them in Enterprise Manager in the correct
order - it has something to do with INDEX on the column, but I haven't found
any information on how to accomplish his.
CREATE INDEX indexname tablename (column) -- doesn't reorder the primary key
the way that I want it to - I was wondering if there was a way to accomplish
this.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1146170512.392795.12240@.i40g2000cwc.googlegroups.com...
> Timothy Ross wrote:
> Tables have no inherent order. The only way to fix the order you see is
> to use an ORDER BY clause in your SELECT statements. Enterprise Manager
> won't do that for you - you need to write your own query. Preferably
> use Query Analyzer instead because it's a much more powerful tool.
> You'll need to familiarize yourself with SQL syntax first but that's
> not so hard for the basic stuff. For example:
> SELECT col1, col2, col3, ...
> FROM your_table
> ORDER BY col1 ;
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>|||On Thu, 27 Apr 2006 16:52:04 -0400, "Timothy Ross"
<ross_timothy@.hotmail.com> wrote:
>I have been told there is a command that will re-order my primary keys
>sequentially so that I can view them in Enterprise Manager in the correct
>order - it has something to do with INDEX on the column, but I haven't foun
d
>any information on how to accomplish his.
If you have a clustered index (or primary key) on the table, then the
physical and logical order will be the same.
But even then, a select statement without an order-by does not seem to
guarantee things will display in order. Just why not, I do not really
understand. May have to do with reuse of freed pages and order of
insertion, so the logical and physical *page* order are not the same,
irrespective of the logical and physical *row* orders.
Josh|||> But even then, a select statement without an order-by does not seem to
> guarantee things will display in order. Just why not, I do not really
> understand. May have to do with reuse of freed pages and order of
> insertion, so the logical and physical *page* order are not the same,
> irrespective of the logical and physical *row* orders.
SQL Server is free to return data in any sequence (e.g. most efficient
manner) unless the query contains ORDER BY. For example, there is a
'merry-go-round' scan feature that allows multiple concurrent queries to
'piggyback' on a scan already in progress. Once the later queries retrieve
the last row, the scan resumes at the beginning and continues until the
initially retrieved row is encountered. This could result in rows returned
in an arbitrary order.
It's good to have an understanding of the physical implementation for
performance analysis. However, you can rely only on the result described by
the SQL query.
Hope this helps.
Dan Guzman
SQL Server MVP
"JXStern" <JXSternChangeX2R@.gte.net> wrote in message
news:gb88529oa6vkkdom9dgbtv9gfhhkh16u7e@.
4ax.com...
> On Thu, 27 Apr 2006 16:52:04 -0400, "Timothy Ross"
> <ross_timothy@.hotmail.com> wrote:
> If you have a clustered index (or primary key) on the table, then the
> physical and logical order will be the same.
> But even then, a select statement without an order-by does not seem to
> guarantee things will display in order. Just why not, I do not really
> understand. May have to do with reuse of freed pages and order of
> insertion, so the logical and physical *page* order are not the same,
> irrespective of the logical and physical *row* orders.
> Josh
>

Primary Key with a datetime datatype

We're seeing a data conversion error after adding a primary key that contains
a datetime column.
SQL profiler indicated the app was passing a date value in format that is
incompatible (passing dd-mm-yyyy). I am able to reproduce the error in Query
Analyzer.
The vendor is insisting that the problem is due to the primary key. To
humor them, I removed the PK's and of course the problem still persists. But
now the vendor is telling us to re-install the app and migrate all the data
again without defining primary key.
Is there something I don't know about the internal storage of a primary
key/datetime datatype that would cause this error?
Responses appreciated!
"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in
Query
> Analyzer.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
Aboslutely not...
But why did the date format that the app is passing change? Does the
vendor claim that it was that way before?
|||SORRY - THIS IS A DUPLICATE. I KEPT GETTING ERROR SAYING MY POST DIDN'T POST.
"Colleen Rossman" wrote:

> We're seeing a data conversion error after adding a primary key that contains
> a datetime column.
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in Query
> Analyzer.
> The vendor is insisting that the problem is due to the primary key. To
> humor them, I removed the PK's and of course the problem still persists. But
> now the vendor is telling us to re-install the app and migrate all the data
> again without defining primary key.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
> Responses appreciated!
>
|||A primary key constraint won't affect the way a date is stored and
interpreted.
If the application passes dates as strings then it should use one of the
standard ISO formats such as YYYYMMDD. That's the best way to be sure that
date strings will be interpreted correctly.
David Portas
SQL Server MVP
|||Yes, the vendor does claim it's 'by design' and it's been this way for a long
time. However I found a 'set dateformat=dmy' statement in the trace output
which works in QA, allowing me to pass ddmmyyyy format without error, but it
didn't work in the app and that's teh real issue here.
Colleen
"Adam Machanic" wrote:

> "Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
> news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> Query
> Aboslutely not...
> But why did the date format that the app is passing change? Does the
> vendor claim that it was that way before?
>
>
|||Perhaps the app passes appropriate SET DATEFORMAT command, but in a different connection? I'm
thinking things like connection pooling etc. It is definitely an app issue, and Profiler should
reveal what is really happening. I'd strongly suggest to the app vendor to use a "safe" format.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:75915596-9A5C-4665-950D-794B05F957C6@.microsoft.com...[vbcol=seagreen]
> Yes, the vendor does claim it's 'by design' and it's been this way for a long
> time. However I found a 'set dateformat=dmy' statement in the trace output
> which works in QA, allowing me to pass ddmmyyyy format without error, but it
> didn't work in the app and that's teh real issue here.
> Colleen
> "Adam Machanic" wrote:
|||Pass/retrieve it as text only. Then post-process
Jeff
"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> We're seeing a data conversion error after adding a primary key that
contains
> a datetime column.
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in
Query
> Analyzer.
> The vendor is insisting that the problem is due to the primary key. To
> humor them, I removed the PK's and of course the problem still persists.
But
> now the vendor is telling us to re-install the app and migrate all the
data
> again without defining primary key.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
> Responses appreciated!
>
sql

Primary Key with a datetime datatype

We're seeing a data conversion error after adding a primary key that contains
a datetime column.
SQL profiler indicated the app was passing a date value in format that is
incompatible (passing dd-mm-yyyy). I am able to reproduce the error in Query
Analyzer.
The vendor is insisting that the problem is due to the primary key. To
humor them, I removed the PK's and of course the problem still persists. But
now the vendor is telling us to re-install the app and migrate all the data
again without defining primary key.
Is there something I don't know about the internal storage of a primary
key/datetime datatype that would cause this error?
Responses appreciated!"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in
Query
> Analyzer.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
Aboslutely not...
But why did the date format that the app is passing change? Does the
vendor claim that it was that way before?|||SORRY - THIS IS A DUPLICATE. I KEPT GETTING ERROR SAYING MY POST DIDN'T POST.
"Colleen Rossman" wrote:
> We're seeing a data conversion error after adding a primary key that contains
> a datetime column.
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in Query
> Analyzer.
> The vendor is insisting that the problem is due to the primary key. To
> humor them, I removed the PK's and of course the problem still persists. But
> now the vendor is telling us to re-install the app and migrate all the data
> again without defining primary key.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
> Responses appreciated!
>|||A primary key constraint won't affect the way a date is stored and
interpreted.
If the application passes dates as strings then it should use one of the
standard ISO formats such as YYYYMMDD. That's the best way to be sure that
date strings will be interpreted correctly.
--
David Portas
SQL Server MVP
--|||Yes, the vendor does claim it's 'by design' and it's been this way for a long
time. However I found a 'set dateformat=dmy' statement in the trace output
which works in QA, allowing me to pass ddmmyyyy format without error, but it
didn't work in the app and that's teh real issue here.
Colleen
"Adam Machanic" wrote:
> "Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
> news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> >
> > SQL profiler indicated the app was passing a date value in format that is
> > incompatible (passing dd-mm-yyyy). I am able to reproduce the error in
> Query
> > Analyzer.
> >
> > Is there something I don't know about the internal storage of a primary
> > key/datetime datatype that would cause this error?
> Aboslutely not...
> But why did the date format that the app is passing change? Does the
> vendor claim that it was that way before?
>
>|||Perhaps the app passes appropriate SET DATEFORMAT command, but in a different connection? I'm
thinking things like connection pooling etc. It is definitely an app issue, and Profiler should
reveal what is really happening. I'd strongly suggest to the app vendor to use a "safe" format.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:75915596-9A5C-4665-950D-794B05F957C6@.microsoft.com...
> Yes, the vendor does claim it's 'by design' and it's been this way for a long
> time. However I found a 'set dateformat=dmy' statement in the trace output
> which works in QA, allowing me to pass ddmmyyyy format without error, but it
> didn't work in the app and that's teh real issue here.
> Colleen
> "Adam Machanic" wrote:
>> "Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
>> news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
>> >
>> > SQL profiler indicated the app was passing a date value in format that is
>> > incompatible (passing dd-mm-yyyy). I am able to reproduce the error in
>> Query
>> > Analyzer.
>> >
>> > Is there something I don't know about the internal storage of a primary
>> > key/datetime datatype that would cause this error?
>> Aboslutely not...
>> But why did the date format that the app is passing change? Does the
>> vendor claim that it was that way before?
>>|||Pass/retrieve it as text only. Then post-process
Jeff
"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> We're seeing a data conversion error after adding a primary key that
contains
> a datetime column.
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in
Query
> Analyzer.
> The vendor is insisting that the problem is due to the primary key. To
> humor them, I removed the PK's and of course the problem still persists.
But
> now the vendor is telling us to re-install the app and migrate all the
data
> again without defining primary key.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
> Responses appreciated!
>

Primary Key with a datetime datatype

We're seeing a data conversion error after adding a primary key that contain
s
a datetime column.
SQL profiler indicated the app was passing a date value in format that is
incompatible (passing dd-mm-yyyy). I am able to reproduce the error in Quer
y
Analyzer.
The vendor is insisting that the problem is due to the primary key. To
humor them, I removed the PK's and of course the problem still persists. Bu
t
now the vendor is telling us to re-install the app and migrate all the data
again without defining primary key.
Is there something I don't know about the internal storage of a primary
key/datetime datatype that would cause this error?
Responses appreciated!"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in
Query
> Analyzer.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
Aboslutely not...
But why did the date format that the app is passing change? Does the
vendor claim that it was that way before?|||SORRY - THIS IS A DUPLICATE. I KEPT GETTING ERROR SAYING MY POST DIDN'T POS
T.
"Colleen Rossman" wrote:

> We're seeing a data conversion error after adding a primary key that conta
ins
> a datetime column.
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in Qu
ery
> Analyzer.
> The vendor is insisting that the problem is due to the primary key. To
> humor them, I removed the PK's and of course the problem still persists.
But
> now the vendor is telling us to re-install the app and migrate all the dat
a
> again without defining primary key.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
> Responses appreciated!
>|||A primary key constraint won't affect the way a date is stored and
interpreted.
If the application passes dates as strings then it should use one of the
standard ISO formats such as YYYYMMDD. That's the best way to be sure that
date strings will be interpreted correctly.
David Portas
SQL Server MVP
--|||Yes, the vendor does claim it's 'by design' and it's been this way for a lon
g
time. However I found a 'set dateformat=dmy' statement in the trace output
which works in QA, allowing me to pass ddmmyyyy format without error, but i
t
didn't work in the app and that's teh real issue here.
Colleen
"Adam Machanic" wrote:

> "Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
> news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> Query
> Aboslutely not...
> But why did the date format that the app is passing change? Does the
> vendor claim that it was that way before?
>
>|||Perhaps the app passes appropriate SET DATEFORMAT command, but in a differen
t connection? I'm
thinking things like connection pooling etc. It is definitely an app issue,
and Profiler should
reveal what is really happening. I'd strongly suggest to the app vendor to u
se a "safe" format.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:75915596-9A5C-4665-950D-794B05F957C6@.microsoft.com...[vbcol=seagreen]
> Yes, the vendor does claim it's 'by design' and it's been this way for a l
ong
> time. However I found a 'set dateformat=dmy' statement in the trace outpu
t
> which works in QA, allowing me to pass ddmmyyyy format without error, but
it
> didn't work in the app and that's teh real issue here.
> Colleen
> "Adam Machanic" wrote:
>|||Pass/retrieve it as text only. Then post-process
Jeff
"Colleen Rossman" <crossman@.discussions.microsoft.com> wrote in message
news:DDBAF283-CC40-408A-B942-428DF8A157E3@.microsoft.com...
> We're seeing a data conversion error after adding a primary key that
contains
> a datetime column.
> SQL profiler indicated the app was passing a date value in format that is
> incompatible (passing dd-mm-yyyy). I am able to reproduce the error in
Query
> Analyzer.
> The vendor is insisting that the problem is due to the primary key. To
> humor them, I removed the PK's and of course the problem still persists.
But
> now the vendor is telling us to re-install the app and migrate all the
data
> again without defining primary key.
> Is there something I don't know about the internal storage of a primary
> key/datetime datatype that would cause this error?
> Responses appreciated!
>

primary key error with INSERT INTO

Using the following t-sql statement on table with a primary key [DateTime], I get a primary key violation. How can I avoid adding duplicate records?

INSERT INTO [destSchema].[destTable]

SELECT t2.*

FROM [srcSchema].[srcTable] t2

LEFT JOIN [destSchema].[destTable] t1

ON t2.[DateTime] = t1.[DateTime]

WHERE (t1.[DateTime] IS NULL) AND (t1.[DateTime] <> t2.[DateTime])

ORDER BY t1.[DateTime];

Is [destTable].[DateTime] the primary key?

Code Snippet

INSERT INTO [destSchema].[destTable]

SELECT

t2.*

FROM

[srcSchema].[srcTable] t2

LEFT OUTER JOIN

[destSchema].[destTable] t1

ON

t2.[DateTime] = t1.[DateTime]

WHERE

t1.[DateTime] IS NULL

|||

Yes

|||

The dupe data can be coming from t2. So, you will have to decide what you want to insert into t1.

This query will give you a list of dupe dates.

Code Snippet

select t2.[DateTime]

from [srcSchema].[srcTable] t2

where not exists(select 1 from [destSchema].[destTable] t1 where t2.[DateTime] = t1.[DateTime])

group by t2.[DateTime]

having count(*)>1

|||

The code to list dupe dates works great. However, the other code generates the same primary key error that I′ve been getting all along:

Msg 2627, Level 14, State 1, Line 1

Violation of PRIMARY KEY constraint 'PK_destTable'. Cannot insert duplicate key in object 'destSchema.destTable'.

The statement has been terminated.

|||

If the code lists dupes, you will have to clean your data in table t2 before you insert it into t1. The bottom line, you have to guarantee the data from t2 is unique before you commit inserting into t1 - this involves either deleting the duped data or only selecting a row for each name. Else, you will get the primary constraint violation. This is by design.

Only you know your data, you will have to make the choice of what to insert into t1. If you post DDL + sample data + expected result here, we might be able to offer a solution.

|||

The following are sample fields in the source table, actual field names vary depending on the source but they all contain DateTime (Field0):

[DateTime] [datetime] NOT NULL,

[Field1] [decimal](10, 2) NULL,

[Field2] [decimal](10, 2) NULL,

[Field3] [decimal](10, 2) NULL,

[Field4] [decimal](10, 2) NULL

Here is some sample data from the source table that demonstrates the problem (non-black lines indicates duplicated rows). Note that the DateTime value is duplicated but the other fields contain different values:

2005-11-28 18:21:00,498.70,498.70,498.70,498.70
2005-11-28 18:22:00,498.50,498.50,498.50,498.50
2005-11-28 18:22:00,502.90,502.90,502.90,502.90
2005-11-28 18:23:00,498.40,498.40,498.40,498.40
2005-11-28 18:26:00,498.30,498.30,498.30,498.30
2005-11-28 18:26:00,502.70,502.70,502.70,502.70
2005-11-28 18:28:00,502.70,502.70,502.70,502.70
2005-11-28 18:28:00,498.40,498.40,498.40,498.40
2005-11-28 18:30:00,502.60,502.60,502.60,502.60
2005-11-28 18:31:00,498.30,498.30,498.30,498.30
2005-11-28 18:32:00,502.60,502.60,502.60,502.60
2005-11-28 18:33:00,502.60,502.60,502.60,502.60
2005-11-28 18:34:00,502.60,502.60,502.60,502.60
2005-11-28 18:36:00,502.50,502.50,502.50,502.50
2005-11-28 18:39:00,502.40,502.40,502.30,502.30
2005-11-28 18:39:00,498.10,498.10,498.00,498.00

Desired results:

2005-11-28 18:21:00,498.70,498.70,498.70,498.70
2005-11-28 18:22:00,498.50,498.50,498.50,498.50
2005-11-28 18:23:00,498.40,498.40,498.40,498.40
2005-11-28 18:26:00,498.30,498.30,498.30,498.30
2005-11-28 18:28:00,502.70,502.70,502.70,502.70
2005-11-28 18:30:00,502.60,502.60,502.60,502.60
2005-11-28 18:31:00,498.30,498.30,498.30,498.30
2005-11-28 18:32:00,502.60,502.60,502.60,502.60
2005-11-28 18:33:00,502.60,502.60,502.60,502.60
2005-11-28 18:34:00,502.60,502.60,502.60,502.60
2005-11-28 18:36:00,502.50,502.50,502.50,502.50
2005-11-28 18:39:00,502.40,502.40,502.30,502.30

Any and all help appreciated.

|||

Here you go.

Code Snippet

create table #tmp([DateTime] [datetime] NOT NULL,
[Field1] [decimal](10, 2) NULL,
[Field2] [decimal](10, 2) NULL,
[Field3] [decimal](10, 2) NULL,
[Field4] [decimal](10, 2) NULL)
go
create table #tmp2([DateTime] [datetime] NOT NULL,
[Field1] [decimal](10, 2) NULL,
[Field2] [decimal](10, 2) NULL,
[Field3] [decimal](10, 2) NULL,
[Field4] [decimal](10, 2) NULL)

go
insert #tmp
select '2005-11-28 18:21:00',498.70,498.70,498.70,498.70
union all select '2005-11-28 18:22:00',498.50,498.50,498.50,498.50
union all select '2005-11-28 18:22:00',502.90,502.90,502.90,502.90
union all select '2005-11-28 18:23:00',498.40,498.40,498.40,498.40
union all select '2005-11-28 18:26:00',498.30,498.30,498.30,498.30
union all select '2005-11-28 18:26:00',502.70,502.70,502.70,502.70
union all select '2005-11-28 18:28:00',502.70,502.70,502.70,502.70
union all select '2005-11-28 18:28:00',498.40,498.40,498.40,498.40
union all select '2005-11-28 18:30:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:31:00',498.30,498.30,498.30,498.30
union all select '2005-11-28 18:32:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:33:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:34:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:36:00',502.50,502.50,502.50,502.50
union all select '2005-11-28 18:39:00',502.40,502.40,502.30,502.30
union all select '2005-11-28 18:39:00',498.10,498.10,498.00,498.00
go
;with cte
as
(select *,
row_number() over(partition by [datetime] order by [datetime] ) r
from #tmp
)
insert #tmp2
select [Datetime],Field1,Field2,Field3,Field4
from cte
where r=1
and not exists(select 1 from #tmp2 t2 where t2.[Datetime]=cte.[Datetime])
go
select * from #tmp2
go
drop table #tmp, #tmp2

|||

With mycte

as

(SELECT myDatatime, f1, f2, f3, f4 FROM

(SELECT myDatatime, f1, f2, f3, f4, ROW_NUMBER() OVER(partition by myDatatime ORDER BY f1) as RowNum

FROM dupDateTimedata) t

WHERE RowNum=1)

SELECT * INTO dupDateTimedataRemoved

FROM mycte

|||

limno, "order by f1" will not give you the "top 1"...i.e. you will get this instead of the desired row.

2005-11-28 18:39:00.000 498.10 498.10 498.00 498.00

|||

Thanks oj for pointing this out. The problem is even with order by [datetime], we may still not get the right result.

We may need a little more clarification from rwbta to confirm your result.

My intention was by using Partion by datetime then I will keep the samllest number for f1 within the same datetime rows.

|||

Since we partition by datetime, order by datetime again will force the engine to generate the rownumber based on the logical order of the rows which we then select only the first row. Essentially, it is equivalent to "select top 1 * from tb" - this is what was asked by the OP as the desired result.

|||

This certainly turned out more complicated than I imagined. What additional information is needed?

Just as a summary, my original intention was to insert records into a new or existing table without including duplicate DateTime (primary key) values. If that's not possible, I would like to remove records in the source table which contain duplicate DateTime values.

Since the fields are not likely to contain exactly the same values in the duplicated records, DISTINCT won't work. Only the DateTime values are duplicated, inserting only the first occurrence of a duplicated DateTime would be acceptable. Or, alternatively, deleting subsequent duplications in the source table.

|||

Below is what I have done to resolve this problem. Add a primary key ID to the source table to aid in identification of duplicate DateTime's. Then delete duplicates. After that I can insert into a new or existing table.

Add PK ID:

ALTER TABLE srcSchema.srcTable

ADD

DataID int NOT NULL IDENTITY(1, 1),

CONSTRAINT PK_srcTable PRIMARY KEY(DataID)

Delete Duplicates:

DELETE FROM

t1

FROM

srcSchema.srcTable t1

INNER JOIN

(

SELECT

MIN(DataID) AS DataID,

[DateTime]

FROM

srcSchema.srcTable

GROUP BY

[DateTime]

HAVING

COUNT(*) > 1

) t2

ON(

t1.[DateTime] = t2.[DateTime]

AND

t1.DataID <> t2.DataID

)

primary key error with INSERT INTO

Using the following t-sql statement on table with a primary key [DateTime], I get a primary key violation. How can I avoid adding duplicate records?

INSERT INTO [destSchema].[destTable]

SELECT t2.*

FROM [srcSchema].[srcTable] t2

LEFT JOIN [destSchema].[destTable] t1

ON t2.[DateTime] = t1.[DateTime]

WHERE (t1.[DateTime] IS NULL) AND (t1.[DateTime] <> t2.[DateTime])

ORDER BY t1.[DateTime];

Is [destTable].[DateTime] the primary key?

Code Snippet

INSERT INTO [destSchema].[destTable]

SELECT

t2.*

FROM

[srcSchema].[srcTable] t2

LEFT OUTER JOIN

[destSchema].[destTable] t1

ON

t2.[DateTime] = t1.[DateTime]

WHERE

t1.[DateTime] IS NULL

|||

Yes

|||

The dupe data can be coming from t2. So, you will have to decide what you want to insert into t1.

This query will give you a list of dupe dates.

Code Snippet

select t2.[DateTime]

from [srcSchema].[srcTable] t2

where not exists(select 1 from [destSchema].[destTable] t1 where t2.[DateTime] = t1.[DateTime])

group by t2.[DateTime]

having count(*)>1

|||

The code to list dupe dates works great. However, the other code generates the same primary key error that I′ve been getting all along:

Msg 2627, Level 14, State 1, Line 1

Violation of PRIMARY KEY constraint 'PK_destTable'. Cannot insert duplicate key in object 'destSchema.destTable'.

The statement has been terminated.

|||

If the code lists dupes, you will have to clean your data in table t2 before you insert it into t1. The bottom line, you have to guarantee the data from t2 is unique before you commit inserting into t1 - this involves either deleting the duped data or only selecting a row for each name. Else, you will get the primary constraint violation. This is by design.

Only you know your data, you will have to make the choice of what to insert into t1. If you post DDL + sample data + expected result here, we might be able to offer a solution.

|||

The following are sample fields in the source table, actual field names vary depending on the source but they all contain DateTime (Field0):

[DateTime] [datetime] NOT NULL,

[Field1] [decimal](10, 2) NULL,

[Field2] [decimal](10, 2) NULL,

[Field3] [decimal](10, 2) NULL,

[Field4] [decimal](10, 2) NULL

Here is some sample data from the source table that demonstrates the problem (non-black lines indicates duplicated rows). Note that the DateTime value is duplicated but the other fields contain different values:

2005-11-28 18:21:00,498.70,498.70,498.70,498.70
2005-11-28 18:22:00,498.50,498.50,498.50,498.50
2005-11-28 18:22:00,502.90,502.90,502.90,502.90
2005-11-28 18:23:00,498.40,498.40,498.40,498.40
2005-11-28 18:26:00,498.30,498.30,498.30,498.30
2005-11-28 18:26:00,502.70,502.70,502.70,502.70
2005-11-28 18:28:00,502.70,502.70,502.70,502.70
2005-11-28 18:28:00,498.40,498.40,498.40,498.40
2005-11-28 18:30:00,502.60,502.60,502.60,502.60
2005-11-28 18:31:00,498.30,498.30,498.30,498.30
2005-11-28 18:32:00,502.60,502.60,502.60,502.60
2005-11-28 18:33:00,502.60,502.60,502.60,502.60
2005-11-28 18:34:00,502.60,502.60,502.60,502.60
2005-11-28 18:36:00,502.50,502.50,502.50,502.50
2005-11-28 18:39:00,502.40,502.40,502.30,502.30
2005-11-28 18:39:00,498.10,498.10,498.00,498.00

Desired results:

2005-11-28 18:21:00,498.70,498.70,498.70,498.70
2005-11-28 18:22:00,498.50,498.50,498.50,498.50
2005-11-28 18:23:00,498.40,498.40,498.40,498.40
2005-11-28 18:26:00,498.30,498.30,498.30,498.30
2005-11-28 18:28:00,502.70,502.70,502.70,502.70
2005-11-28 18:30:00,502.60,502.60,502.60,502.60
2005-11-28 18:31:00,498.30,498.30,498.30,498.30
2005-11-28 18:32:00,502.60,502.60,502.60,502.60
2005-11-28 18:33:00,502.60,502.60,502.60,502.60
2005-11-28 18:34:00,502.60,502.60,502.60,502.60
2005-11-28 18:36:00,502.50,502.50,502.50,502.50
2005-11-28 18:39:00,502.40,502.40,502.30,502.30

Any and all help appreciated.

|||

Here you go.

Code Snippet

create table #tmp([DateTime] [datetime] NOT NULL,
[Field1] [decimal](10, 2) NULL,
[Field2] [decimal](10, 2) NULL,
[Field3] [decimal](10, 2) NULL,
[Field4] [decimal](10, 2) NULL)
go
create table #tmp2([DateTime] [datetime] NOT NULL,
[Field1] [decimal](10, 2) NULL,
[Field2] [decimal](10, 2) NULL,
[Field3] [decimal](10, 2) NULL,
[Field4] [decimal](10, 2) NULL)

go
insert #tmp
select '2005-11-28 18:21:00',498.70,498.70,498.70,498.70
union all select '2005-11-28 18:22:00',498.50,498.50,498.50,498.50
union all select '2005-11-28 18:22:00',502.90,502.90,502.90,502.90
union all select '2005-11-28 18:23:00',498.40,498.40,498.40,498.40
union all select '2005-11-28 18:26:00',498.30,498.30,498.30,498.30
union all select '2005-11-28 18:26:00',502.70,502.70,502.70,502.70
union all select '2005-11-28 18:28:00',502.70,502.70,502.70,502.70
union all select '2005-11-28 18:28:00',498.40,498.40,498.40,498.40
union all select '2005-11-28 18:30:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:31:00',498.30,498.30,498.30,498.30
union all select '2005-11-28 18:32:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:33:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:34:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:36:00',502.50,502.50,502.50,502.50
union all select '2005-11-28 18:39:00',502.40,502.40,502.30,502.30
union all select '2005-11-28 18:39:00',498.10,498.10,498.00,498.00
go
;with cte
as
(select *,
row_number() over(partition by [datetime] order by [datetime] ) r
from #tmp
)
insert #tmp2
select [Datetime],Field1,Field2,Field3,Field4
from cte
where r=1
and not exists(select 1 from #tmp2 t2 where t2.[Datetime]=cte.[Datetime])
go
select * from #tmp2
go
drop table #tmp, #tmp2

|||

With mycte

as

(SELECT myDatatime, f1, f2, f3, f4 FROM

(SELECT myDatatime, f1, f2, f3, f4, ROW_NUMBER() OVER(partition by myDatatime ORDER BY f1) as RowNum

FROM dupDateTimedata) t

WHERE RowNum=1)

SELECT * INTO dupDateTimedataRemoved

FROM mycte

|||

limno, "order by f1" will not give you the "top 1"...i.e. you will get this instead of the desired row.

2005-11-28 18:39:00.000 498.10 498.10 498.00 498.00

|||

Thanks oj for pointing this out. The problem is even with order by [datetime], we may still not get the right result.

We may need a little more clarification from rwbta to confirm your result.

My intention was by using Partion by datetime then I will keep the samllest number for f1 within the same datetime rows.

|||

Since we partition by datetime, order by datetime again will force the engine to generate the rownumber based on the logical order of the rows which we then select only the first row. Essentially, it is equivalent to "select top 1 * from tb" - this is what was asked by the OP as the desired result.

|||

This certainly turned out more complicated than I imagined. What additional information is needed?

Just as a summary, my original intention was to insert records into a new or existing table without including duplicate DateTime (primary key) values. If that's not possible, I would like to remove records in the source table which contain duplicate DateTime values.

Since the fields are not likely to contain exactly the same values in the duplicated records, DISTINCT won't work. Only the DateTime values are duplicated, inserting only the first occurrence of a duplicated DateTime would be acceptable. Or, alternatively, deleting subsequent duplications in the source table.

|||

Below is what I have done to resolve this problem. Add a primary key ID to the source table to aid in identification of duplicate DateTime's. Then delete duplicates. After that I can insert into a new or existing table.

Add PK ID:

ALTER TABLE srcSchema.srcTable

ADD

DataID int NOT NULL IDENTITY(1, 1),

CONSTRAINT PK_srcTable PRIMARY KEY(DataID)

Delete Duplicates:

DELETE FROM

t1

FROM

srcSchema.srcTable t1

INNER JOIN

(

SELECT

MIN(DataID) AS DataID,

[DateTime]

FROM

srcSchema.srcTable

GROUP BY

[DateTime]

HAVING

COUNT(*) > 1

) t2

ON(

t1.[DateTime] = t2.[DateTime]

AND

t1.DataID <> t2.DataID

)

primary key error with INSERT INTO

Using the following t-sql statement on table with a primary key [DateTime], I get a primary key violation. How can I avoid adding duplicate records?

INSERT INTO [destSchema].[destTable]

SELECT t2.*

FROM [srcSchema].[srcTable] t2

LEFT JOIN [destSchema].[destTable] t1

ON t2.[DateTime] = t1.[DateTime]

WHERE (t1.[DateTime] IS NULL) AND (t1.[DateTime] <> t2.[DateTime])

ORDER BY t1.[DateTime];

Is [destTable].[DateTime] the primary key?

Code Snippet

INSERT INTO [destSchema].[destTable]

SELECT

t2.*

FROM

[srcSchema].[srcTable] t2

LEFT OUTER JOIN

[destSchema].[destTable] t1

ON

t2.[DateTime] = t1.[DateTime]

WHERE

t1.[DateTime] IS NULL

|||

Yes

|||

The dupe data can be coming from t2. So, you will have to decide what you want to insert into t1.

This query will give you a list of dupe dates.

Code Snippet

select t2.[DateTime]

from [srcSchema].[srcTable] t2

where not exists(select 1 from [destSchema].[destTable] t1 where t2.[DateTime] = t1.[DateTime])

group by t2.[DateTime]

having count(*)>1

|||

The code to list dupe dates works great. However, the other code generates the same primary key error that I′ve been getting all along:

Msg 2627, Level 14, State 1, Line 1

Violation of PRIMARY KEY constraint 'PK_destTable'. Cannot insert duplicate key in object 'destSchema.destTable'.

The statement has been terminated.

|||

If the code lists dupes, you will have to clean your data in table t2 before you insert it into t1. The bottom line, you have to guarantee the data from t2 is unique before you commit inserting into t1 - this involves either deleting the duped data or only selecting a row for each name. Else, you will get the primary constraint violation. This is by design.

Only you know your data, you will have to make the choice of what to insert into t1. If you post DDL + sample data + expected result here, we might be able to offer a solution.

|||

The following are sample fields in the source table, actual field names vary depending on the source but they all contain DateTime (Field0):

[DateTime] [datetime] NOT NULL,

[Field1] [decimal](10, 2) NULL,

[Field2] [decimal](10, 2) NULL,

[Field3] [decimal](10, 2) NULL,

[Field4] [decimal](10, 2) NULL

Here is some sample data from the source table that demonstrates the problem (non-black lines indicates duplicated rows). Note that the DateTime value is duplicated but the other fields contain different values:

2005-11-28 18:21:00,498.70,498.70,498.70,498.70
2005-11-28 18:22:00,498.50,498.50,498.50,498.50
2005-11-28 18:22:00,502.90,502.90,502.90,502.90
2005-11-28 18:23:00,498.40,498.40,498.40,498.40
2005-11-28 18:26:00,498.30,498.30,498.30,498.30
2005-11-28 18:26:00,502.70,502.70,502.70,502.70
2005-11-28 18:28:00,502.70,502.70,502.70,502.70
2005-11-28 18:28:00,498.40,498.40,498.40,498.40
2005-11-28 18:30:00,502.60,502.60,502.60,502.60
2005-11-28 18:31:00,498.30,498.30,498.30,498.30
2005-11-28 18:32:00,502.60,502.60,502.60,502.60
2005-11-28 18:33:00,502.60,502.60,502.60,502.60
2005-11-28 18:34:00,502.60,502.60,502.60,502.60
2005-11-28 18:36:00,502.50,502.50,502.50,502.50
2005-11-28 18:39:00,502.40,502.40,502.30,502.30
2005-11-28 18:39:00,498.10,498.10,498.00,498.00

Desired results:

2005-11-28 18:21:00,498.70,498.70,498.70,498.70
2005-11-28 18:22:00,498.50,498.50,498.50,498.50
2005-11-28 18:23:00,498.40,498.40,498.40,498.40
2005-11-28 18:26:00,498.30,498.30,498.30,498.30
2005-11-28 18:28:00,502.70,502.70,502.70,502.70
2005-11-28 18:30:00,502.60,502.60,502.60,502.60
2005-11-28 18:31:00,498.30,498.30,498.30,498.30
2005-11-28 18:32:00,502.60,502.60,502.60,502.60
2005-11-28 18:33:00,502.60,502.60,502.60,502.60
2005-11-28 18:34:00,502.60,502.60,502.60,502.60
2005-11-28 18:36:00,502.50,502.50,502.50,502.50
2005-11-28 18:39:00,502.40,502.40,502.30,502.30

Any and all help appreciated.

|||

Here you go.

Code Snippet

create table #tmp([DateTime] [datetime] NOT NULL,
[Field1] [decimal](10, 2) NULL,
[Field2] [decimal](10, 2) NULL,
[Field3] [decimal](10, 2) NULL,
[Field4] [decimal](10, 2) NULL)
go
create table #tmp2([DateTime] [datetime] NOT NULL,
[Field1] [decimal](10, 2) NULL,
[Field2] [decimal](10, 2) NULL,
[Field3] [decimal](10, 2) NULL,
[Field4] [decimal](10, 2) NULL)

go
insert #tmp
select '2005-11-28 18:21:00',498.70,498.70,498.70,498.70
union all select '2005-11-28 18:22:00',498.50,498.50,498.50,498.50
union all select '2005-11-28 18:22:00',502.90,502.90,502.90,502.90
union all select '2005-11-28 18:23:00',498.40,498.40,498.40,498.40
union all select '2005-11-28 18:26:00',498.30,498.30,498.30,498.30
union all select '2005-11-28 18:26:00',502.70,502.70,502.70,502.70
union all select '2005-11-28 18:28:00',502.70,502.70,502.70,502.70
union all select '2005-11-28 18:28:00',498.40,498.40,498.40,498.40
union all select '2005-11-28 18:30:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:31:00',498.30,498.30,498.30,498.30
union all select '2005-11-28 18:32:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:33:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:34:00',502.60,502.60,502.60,502.60
union all select '2005-11-28 18:36:00',502.50,502.50,502.50,502.50
union all select '2005-11-28 18:39:00',502.40,502.40,502.30,502.30
union all select '2005-11-28 18:39:00',498.10,498.10,498.00,498.00
go
;with cte
as
(select *,
row_number() over(partition by [datetime] order by [datetime] ) r
from #tmp
)
insert #tmp2
select [Datetime],Field1,Field2,Field3,Field4
from cte
where r=1
and not exists(select 1 from #tmp2 t2 where t2.[Datetime]=cte.[Datetime])
go
select * from #tmp2
go
drop table #tmp, #tmp2

|||

With mycte

as

(SELECT myDatatime, f1, f2, f3, f4 FROM

(SELECT myDatatime, f1, f2, f3, f4, ROW_NUMBER() OVER(partition by myDatatime ORDER BY f1) as RowNum

FROM dupDateTimedata) t

WHERE RowNum=1)

SELECT * INTO dupDateTimedataRemoved

FROM mycte

|||

limno, "order by f1" will not give you the "top 1"...i.e. you will get this instead of the desired row.

2005-11-28 18:39:00.000 498.10 498.10 498.00 498.00

|||

Thanks oj for pointing this out. The problem is even with order by [datetime], we may still not get the right result.

We may need a little more clarification from rwbta to confirm your result.

My intention was by using Partion by datetime then I will keep the samllest number for f1 within the same datetime rows.

|||

Since we partition by datetime, order by datetime again will force the engine to generate the rownumber based on the logical order of the rows which we then select only the first row. Essentially, it is equivalent to "select top 1 * from tb" - this is what was asked by the OP as the desired result.

|||

This certainly turned out more complicated than I imagined. What additional information is needed?

Just as a summary, my original intention was to insert records into a new or existing table without including duplicate DateTime (primary key) values. If that's not possible, I would like to remove records in the source table which contain duplicate DateTime values.

Since the fields are not likely to contain exactly the same values in the duplicated records, DISTINCT won't work. Only the DateTime values are duplicated, inserting only the first occurrence of a duplicated DateTime would be acceptable. Or, alternatively, deleting subsequent duplications in the source table.

|||

Below is what I have done to resolve this problem. Add a primary key ID to the source table to aid in identification of duplicate DateTime's. Then delete duplicates. After that I can insert into a new or existing table.

Add PK ID:

ALTER TABLE srcSchema.srcTable

ADD

DataID int NOT NULL IDENTITY(1, 1),

CONSTRAINT PK_srcTable PRIMARY KEY(DataID)

Delete Duplicates:

DELETE FROM

t1

FROM

srcSchema.srcTable t1

INNER JOIN

(

SELECT

MIN(DataID) AS DataID,

[DateTime]

FROM

srcSchema.srcTable

GROUP BY

[DateTime]

HAVING

COUNT(*) > 1

) t2

ON(

t1.[DateTime] = t2.[DateTime]

AND

t1.DataID <> t2.DataID

)

'PRIMARY' filegroup full error

When adding records that would take a SQL Server
Developer Ed. table over 2 Gb, I receive an error that
says "Could not allocate space for object 'MyTableName'
in database 'MyDb' because the 'PRIMARY' filegroup is
full." What do I need to do to get around this error?
Thanks in advance,
JoeAre you referring the Desktop (MSDE) edition? This is a known
limitation of that edition and there is no workaround.
The Developer edition has no size limitation. You can expand your
database or add additional files to get around the error.
--
Hope this helps.
Dan Guzman
SQL Server MVP
--
SQL FAQ links (courtesy Neil Pike):
http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--
"Joe" <joe.murray@.jmaconsulting.biz> wrote in message
news:0fb401c36738$0c3b53b0$a601280a@.phx.gbl...
> When adding records that would take a SQL Server
> Developer Ed. table over 2 Gb, I receive an error that
> says "Could not allocate space for object 'MyTableName'
> in database 'MyDb' because the 'PRIMARY' filegroup is
> full." What do I need to do to get around this error?
> Thanks in advance,
> Joe

Preventing customers from hacking my MSDE database?

Recently I installed a commercial client-only product utilizing an
MSDE database.
The product installed its own instance of MSDE rather than adding a
database to the default instance (or install a default instance).
Of course, not with a blank sa password, so I could not access it
just by firing up Enterprise Manager or Query Analyzer.
Still, I was curious about the structure of the database, so
all I had to do to gain access to the table structure and data was to
stop the service for the MSDE instance, locate the database and log
files, copy them to another location, and attach them to the default
instance. I now had access to the table structure and all the data.
Still, the triggers and stored procedures were stored with encryption,
but this was no problem for a tool like Orbital's SQL Decryptor or a
couple of other scripts freely available on the Internet.
Question is: Is there anything the author could have done to prevent
me from doing any of the above? Or to put it another way: Is there
anything I can do to prevent others from accessing data in my own
programs in unauthorized ways?
TIA,
JBHave you tried to remove the user from System Admin server role and give
them an appropriate permissions?
"Joergen Bech @. post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:cjdpn0hjt5dtilasl28hg29g9qt76c0v5o@.
4ax.com...
> Recently I installed a commercial client-only product utilizing an
> MSDE database.
> The product installed its own instance of MSDE rather than adding a
> database to the default instance (or install a default instance).
> Of course, not with a blank sa password, so I could not access it
> just by firing up Enterprise Manager or Query Analyzer.
> Still, I was curious about the structure of the database, so
> all I had to do to gain access to the table structure and data was to
> stop the service for the MSDE instance, locate the database and log
> files, copy them to another location, and attach them to the default
> instance. I now had access to the table structure and all the data.
> Still, the triggers and stored procedures were stored with encryption,
> but this was no problem for a tool like Orbital's SQL Decryptor or a
> couple of other scripts freely available on the Internet.
> Question is: Is there anything the author could have done to prevent
> me from doing any of the above? Or to put it another way: Is there
> anything I can do to prevent others from accessing data in my own
> programs in unauthorized ways?
> TIA,
> JB
>
>|||Basically no. If it is installed on their server then most likely they will
have the ability to access your files and or the db directly. Your best
recourse is to have very good copywrite, NDA's etc. in place.
Andrew J. Kelly SQL MVP
"Joergen Bech @. post1.tele.dk>" <jbech<NOSPAMNOSPAM> wrote in message
news:cjdpn0hjt5dtilasl28hg29g9qt76c0v5o@.
4ax.com...
> Recently I installed a commercial client-only product utilizing an
> MSDE database.
> The product installed its own instance of MSDE rather than adding a
> database to the default instance (or install a default instance).
> Of course, not with a blank sa password, so I could not access it
> just by firing up Enterprise Manager or Query Analyzer.
> Still, I was curious about the structure of the database, so
> all I had to do to gain access to the table structure and data was to
> stop the service for the MSDE instance, locate the database and log
> files, copy them to another location, and attach them to the default
> instance. I now had access to the table structure and all the data.
> Still, the triggers and stored procedures were stored with encryption,
> but this was no problem for a tool like Orbital's SQL Decryptor or a
> couple of other scripts freely available on the Internet.
> Question is: Is there anything the author could have done to prevent
> me from doing any of the above? Or to put it another way: Is there
> anything I can do to prevent others from accessing data in my own
> programs in unauthorized ways?
> TIA,
> JB
>
>