Odd INSERT INTO issue with replication setup

I've got a db setup for replication. Replication works fine in both
directions. However ...
On the SQL2k backend, I can do an INSERT INTO to a particular table
(Results) with no problem. When I try to do the same INSERT INTO on the
Results table with SQLCE, I get the error message, "A duplicate value cannot
be inserted into a unique index". Note that I can do an UPDATE on the
Results table with no problem.
I do have one guidcol (uniqueidentifier, Non-null) on the SQL Server table.
To simplify matters, I have NO indexes (except the PK) and a single INT
primary key.
I've noticed in the Query Analyzer (SQLCE), that after a replication sync,
there are now 3 index (?) columns on the table, 2 of which are not in the
main SQLServer table.
s_Generation (int)
s_RowLineage (varbinary)
rowguid (uniqueidentifier)
Is this INSERT INTO failure somehow related to the extra columns added or is
this a rowguid problem?
Earl,
does your INSERT INTO specify the guid's value?
Rgds,
Paul Ibison
|||No it does not. My understanding is that this is a read-only column?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:eVEX24TVFHA.3044@.TK2MSFTNGP10.phx.gbl...
> Earl,
> does your INSERT INTO specify the guid's value?
> Rgds,
> Paul Ibison
>
|||If there's only one index on the PK and you're not entering a duplicate
record, then the problem must be with the system tables. I notice that you
have posted this same question some time ago without it being solved. Have
you reinitialized in the meantime? Does the error occur after
reinitialization? How about if you remove replication and set it up - is it
reproducible?
Rgds,
Paul Ibison
|||Yes, I actually removed replication from SQL2k, made sure everything was
cleaned out of the database and set it all back up (I drop the database
during the replication process on the subscriber/SQLCE side). I'm really
scratching my head on this one, because everything "looks" correct. I posted
the code for the INSERT INTO logic over in the
microsoft.public.dotnet.framework.adonet forum, just in case I missed
something on that side of it. Apparently it is accurate, as I've had no
responses to a request for input.
What is left? Does the SQLCE database not actually generate a guid for that
column?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:eRws5BYVFHA.628@.TK2MSFTNGP09.phx.gbl...
> If there's only one index on the PK and you're not entering a duplicate
> record, then the problem must be with the system tables. I notice that you
> have posted this same question some time ago without it being solved. Have
> you reinitialized in the meantime? Does the error occur after
> reinitialization? How about if you remove replication and set it up - is
> it reproducible?
> Rgds,
> Paul Ibison
>

ODBC vs OLE DB

Hi All, does anybody know the pros and cons of using ODBC to connect an Access front end to an SQL backend, vs using Access projects.
ThanksAre you thinking of migrating an existing application or starting a new project. In case of migration, ODBC gets things running much faster and you have all that nifty access-features you are used to work with. Porting to adp ends up with a lot of rewriting. On the other hand, you have immediate access to stored procedures, views, triggers, transactions etc. that are more then useful.
ADP is, uhm, not-so-well documented imo. You are forced to use ADO which is somehow inconvinient in the beginning but more robust in my experience.
So if you are migrating, it mainly depends on your need to use SQL-Server features.
If you are starting a new project and have the time (and nerve) to play around with something new, I'd recommend to go for adp.|||My case is the second one. I am thinking of starting a new Project.
The only think that made me think twice about it is that when I connect to my SQL backend, its faster than my adp file that is connected to the same SQL database from the same machine. Maybe thats because I don't have a lot of data at this point.

Thanks

Originally posted by chrisp_999
Are you thinking of migrating an existing application or starting a new project. In case of migration, ODBC gets things running much faster and you have all that nifty access-features you are used to work with. Porting to adp ends up with a lot of rewriting. On the other hand, you have immediate access to stored procedures, views, triggers, transactions etc. that are more then useful.
ADP is, uhm, not-so-well documented imo. You are forced to use ADO which is somehow inconvinient in the beginning but more robust in my experience.
So if you are migrating, it mainly depends on your need to use SQL-Server features.
If you are starting a new project and have the time (and nerve) to play around with something new, I'd recommend to go for adp.|||ODBC connections seem to be faster locally. My expieriences for network connections are exactly the opposite.

You should use Acess 2002 (adp is new for 2000 and not that stable;) and you should make yourself familiar with Enterprise Manager and Queray analyzer (if you aren't already). Then you have data and presentation separated, a fairly good ide and admin environment and all MSSQL features at hand.

We migrated a large project late 2001 and are since working with adp and I'm quite happy with it.