Showing posts with label updating. Show all posts
Showing posts with label updating. Show all posts

Monday, March 12, 2012

IDENTITY Problems Updating ZipCode Table

I am having problems updating my zip code table that contains zip, city, state, long, lat, ect..

I have the latest CSV file, I tried to use the import wizard in SQL Server 2000 Enterprise Manager.
I set the ID field as <ignore> and specified the appropriate columns for the rest of the data matching from CSV to already designed and working zip code table. Also I checked the box that said "Delete Rows in Destination Table" as well as "Enable Identity Insert" was checked

I ran the wizard, and now I have empty table and it will not insert any records because the error said that the identity column can not accept NULL.

What do I do? I am not updating the identify column so Is it telling me it can't insert NULL into ID?

Any suggestions...

Thanks,
LitoI set the ID field as <ignore>
...
as well as "Enable Identity Insert" was checked
...
error said that the identity column can not accept NULL.

You are inserting NULL into the ID field, because you have "<ignore>" selected for the ID column, and "Enable Identity Insert" checked. You need to uncheck "Enable Identity Insert" and this should work.|||For the 5th Time I repeated the process and this time i did not check "Enable Identity Insert" and it worked.

Sory to bother you, I was just getting frustrated with this stupid problem|||That's Ok... I think the reason that most of us hang out here is to give folks a hand (and occaisionally make the others say "Doh, why didn't I think of that!"). As long as life is good now, that is all that counts!

-PatP

Identity problem. (Need generate on subscriber new identity values)

If you change the publication to queued updating, use
automatic identity range management and don't run the
queue reader, you should achieve what you require.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
But where in that case subcribers updates will be stored? On distributor?
Is it known bug with incorrect handling identity values in replications? Or
it is my own issue?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:050b01c50853$c6e94010$a601280a@.phx.gbl...
> If you change the publication to queued updating, use
> automatic identity range management and don't run the
> queue reader, you should achieve what you require.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||The subscriber updates will be held on the queue table at
the subscriber, or you could remove the subscriber
triggers. It is assumed that subscribers are read only in
normal circumstances, so any issues regarding data
changes at a subscriber and problems with identities on
the subscriber are not really catered for. Identities are
only coded for if the subscriber uses immediate updating
or queued updating.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Sunday, February 19, 2012

Identifying what Apps are using a database

I'm looking for a little insight on identifying what apps
are updating a particular database. Basically we have a
front end developed for the db but some people may have
created Access dbs and processes in Access to do updates.
I need to determine if this is happening since we may be
moving the db to a different sql server. SQL Profiler
would work, but it's hit and miss. Plus I'd have to let
it run for a few days which would create a huge trace
file. If I did let it run for a few days, I still may not
capture and activity from Access if they didn't happen to
run any Access updates during that time. Is there
anything out there that can help me?
Thanks,
Van Jones
"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:012401c4f75f$6fe0e520$a601280a@.phx.gbl...
> I'm looking for a little insight on identifying what apps
> are updating a particular database. Basically we have a
> front end developed for the db but some people may have
> created Access dbs and processes in Access to do updates.
> I need to determine if this is happening since we may be
> moving the db to a different sql server. SQL Profiler
> would work, but it's hit and miss. Plus I'd have to let
> it run for a few days which would create a huge trace
> file. If I did let it run for a few days, I still may not
> capture and activity from Access if they didn't happen to
> run any Access updates during that time. Is there
> anything out there that can help me?
> Thanks,
> Van Jones
I would still go with Profiler. Take a look at the Filters tab. You can
do things like: NOT LIKE and add all of the known applications that will
log in. You can weed out just about all the activity that you don't want
to see. Then your trace file will not be enormous.
The other suggestion is to turn on profiler and ask everyone to hit the
server with their updates so that you can capture everything in one go.
Rick Sawtell
MCT, MCSD, MCDBA
|||
>--Original Message--
>"Van Jones" <anonymous@.discussions.microsoft.com> wrote
in message[vbcol=seagreen]
>news:012401c4f75f$6fe0e520$a601280a@.phx.gbl...
apps[vbcol=seagreen]
updates.[vbcol=seagreen]
not[vbcol=seagreen]
to
>
>I would still go with Profiler. Take a look at the
Filters tab. You can
>do things like: NOT LIKE and add all of the known
applications that will
>log in. You can weed out just about all the activity
that you don't want
>to see. Then your trace file will not be enormous.
>The other suggestion is to turn on profiler and ask
everyone to hit the
>server with their updates so that you can capture
everything in one go.
>
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>.
Yea, I figure profiler might be the only way. The problem
is...is that I don't know if anybody has any Access
processes that update the db. I've been told that they
might. If they do, it could be quartly or even year end
processes that I wouldn't capture if I ran a trace for a
few days.
|||"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:1d5c01c4f761$bc059f70$a401280a@.phx.gbl...
> in message
> apps
> updates.
> not
> to
> Filters tab. You can
> applications that will
> that you don't want
> everyone to hit the
> everything in one go.
> Yea, I figure profiler might be the only way. The problem
> is...is that I don't know if anybody has any Access
> processes that update the db. I've been told that they
> might. If they do, it could be quartly or even year end
> processes that I wouldn't capture if I ran a trace for a
> few days.
Can you take an inventory of the applications that are hitting your
database? You should have this list regardless.
Another method. (Muahahahaha) Change the login credentials.
Rick Sawtell
MCT, MCSD, MCDBA

Identifying what Apps are using a database

I'm looking for a little insight on identifying what apps
are updating a particular database. Basically we have a
front end developed for the db but some people may have
created Access dbs and processes in Access to do updates.
I need to determine if this is happening since we may be
moving the db to a different sql server. SQL Profiler
would work, but it's hit and miss. Plus I'd have to let
it run for a few days which would create a huge trace
file. If I did let it run for a few days, I still may not
capture and activity from Access if they didn't happen to
run any Access updates during that time. Is there
anything out there that can help me?
Thanks,
Van Jones"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:012401c4f75f$6fe0e520$a601280a@.phx.gbl...
> I'm looking for a little insight on identifying what apps
> are updating a particular database. Basically we have a
> front end developed for the db but some people may have
> created Access dbs and processes in Access to do updates.
> I need to determine if this is happening since we may be
> moving the db to a different sql server. SQL Profiler
> would work, but it's hit and miss. Plus I'd have to let
> it run for a few days which would create a huge trace
> file. If I did let it run for a few days, I still may not
> capture and activity from Access if they didn't happen to
> run any Access updates during that time. Is there
> anything out there that can help me?
> Thanks,
> Van Jones
I would still go with Profiler. Take a look at the Filters tab. You can
do things like: NOT LIKE and add all of the known applications that will
log in. You can weed out just about all the activity that you don't want
to see. Then your trace file will not be enormous.
The other suggestion is to turn on profiler and ask everyone to hit the
server with their updates so that you can capture everything in one go.
Rick Sawtell
MCT, MCSD, MCDBA|||>--Original Message--
>"Van Jones" <anonymous@.discussions.microsoft.com> wrote
in message
>news:012401c4f75f$6fe0e520$a601280a@.phx.gbl...
>> I'm looking for a little insight on identifying what
apps
>> are updating a particular database. Basically we have a
>> front end developed for the db but some people may have
>> created Access dbs and processes in Access to do
updates.
>> I need to determine if this is happening since we may be
>> moving the db to a different sql server. SQL Profiler
>> would work, but it's hit and miss. Plus I'd have to let
>> it run for a few days which would create a huge trace
>> file. If I did let it run for a few days, I still may
not
>> capture and activity from Access if they didn't happen
to
>> run any Access updates during that time. Is there
>> anything out there that can help me?
>> Thanks,
>> Van Jones
>
>I would still go with Profiler. Take a look at the
Filters tab. You can
>do things like: NOT LIKE and add all of the known
applications that will
>log in. You can weed out just about all the activity
that you don't want
>to see. Then your trace file will not be enormous.
>The other suggestion is to turn on profiler and ask
everyone to hit the
>server with their updates so that you can capture
everything in one go.
>
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>.
Yea, I figure profiler might be the only way. The problem
is...is that I don't know if anybody has any Access
processes that update the db. I've been told that they
might. If they do, it could be quartly or even year end
processes that I wouldn't capture if I ran a trace for a
few days.|||"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:1d5c01c4f761$bc059f70$a401280a@.phx.gbl...
>>--Original Message--
>>"Van Jones" <anonymous@.discussions.microsoft.com> wrote
> in message
>>news:012401c4f75f$6fe0e520$a601280a@.phx.gbl...
>> I'm looking for a little insight on identifying what
> apps
>> are updating a particular database. Basically we have a
>> front end developed for the db but some people may have
>> created Access dbs and processes in Access to do
> updates.
>> I need to determine if this is happening since we may be
>> moving the db to a different sql server. SQL Profiler
>> would work, but it's hit and miss. Plus I'd have to let
>> it run for a few days which would create a huge trace
>> file. If I did let it run for a few days, I still may
> not
>> capture and activity from Access if they didn't happen
> to
>> run any Access updates during that time. Is there
>> anything out there that can help me?
>> Thanks,
>> Van Jones
>>
>>I would still go with Profiler. Take a look at the
> Filters tab. You can
>>do things like: NOT LIKE and add all of the known
> applications that will
>>log in. You can weed out just about all the activity
> that you don't want
>>to see. Then your trace file will not be enormous.
>>The other suggestion is to turn on profiler and ask
> everyone to hit the
>>server with their updates so that you can capture
> everything in one go.
>>
>>Rick Sawtell
>>MCT, MCSD, MCDBA
>>
>>.
> Yea, I figure profiler might be the only way. The problem
> is...is that I don't know if anybody has any Access
> processes that update the db. I've been told that they
> might. If they do, it could be quartly or even year end
> processes that I wouldn't capture if I ran a trace for a
> few days.
Can you take an inventory of the applications that are hitting your
database? You should have this list regardless.
Another method. (Muahahahaha) Change the login credentials.
Rick Sawtell
MCT, MCSD, MCDBA

Identifying what Apps are using a database

I'm looking for a little insight on identifying what apps
are updating a particular database. Basically we have a
front end developed for the db but some people may have
created Access dbs and processes in Access to do updates.
I need to determine if this is happening since we may be
moving the db to a different sql server. SQL Profiler
would work, but it's hit and miss. Plus I'd have to let
it run for a few days which would create a huge trace
file. If I did let it run for a few days, I still may not
capture and activity from Access if they didn't happen to
run any Access updates during that time. Is there
anything out there that can help me?
Thanks,
Van Jones"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:012401c4f75f$6fe0e520$a601280a@.phx.gbl...
> I'm looking for a little insight on identifying what apps
> are updating a particular database. Basically we have a
> front end developed for the db but some people may have
> created Access dbs and processes in Access to do updates.
> I need to determine if this is happening since we may be
> moving the db to a different sql server. SQL Profiler
> would work, but it's hit and miss. Plus I'd have to let
> it run for a few days which would create a huge trace
> file. If I did let it run for a few days, I still may not
> capture and activity from Access if they didn't happen to
> run any Access updates during that time. Is there
> anything out there that can help me?
> Thanks,
> Van Jones
I would still go with Profiler. Take a look at the Filters tab. You can
do things like: NOT LIKE and add all of the known applications that will
log in. You can weed out just about all the activity that you don't want
to see. Then your trace file will not be enormous.
The other suggestion is to turn on profiler and ask everyone to hit the
server with their updates so that you can capture everything in one go.
Rick Sawtell
MCT, MCSD, MCDBA|||
>--Original Message--
>"Van Jones" <anonymous@.discussions.microsoft.com> wrote
in message
>news:012401c4f75f$6fe0e520$a601280a@.phx.gbl...
apps[vbcol=seagreen]
updates.[vbcol=seagreen]
not[vbcol=seagreen]
to[vbcol=seagreen]
>
>I would still go with Profiler. Take a look at the
Filters tab. You can
>do things like: NOT LIKE and add all of the known
applications that will
>log in. You can weed out just about all the activity
that you don't want
>to see. Then your trace file will not be enormous.
>The other suggestion is to turn on profiler and ask
everyone to hit the
>server with their updates so that you can capture
everything in one go.
>
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>.
Yea, I figure profiler might be the only way. The problem
is...is that I don't know if anybody has any Access
processes that update the db. I've been told that they
might. If they do, it could be quartly or even year end
processes that I wouldn't capture if I ran a trace for a
few days.|||"Van Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:1d5c01c4f761$bc059f70$a401280a@.phx.gbl...
>
> in message
> apps
> updates.
> not
> to
> Filters tab. You can
> applications that will
> that you don't want
> everyone to hit the
> everything in one go.
> Yea, I figure profiler might be the only way. The problem
> is...is that I don't know if anybody has any Access
> processes that update the db. I've been told that they
> might. If they do, it could be quartly or even year end
> processes that I wouldn't capture if I ran a trace for a
> few days.
Can you take an inventory of the applications that are hitting your
database? You should have this list regardless.
Another method. (Muahahahaha) Change the login credentials.
Rick Sawtell
MCT, MCSD, MCDBA