>If anything auto-increment in SQL Server should be more reliable than in FoxPro. ANd if that doesn't work for your situation you can use a stored proc to increment a counter (I do that in my business objects actually to get Ids passed back before an insert actually occurs).
If I identify the primary key column as Identity in the SQL Server database, I am ok. I am just having some problems presently with the package, where, despite the fact that I checked Keep Identity, this does not upscale that setting to the SQL Server database. It used to work a few hours ago. But, now it doesn't work anymore.
>Do you really need dates that go that far back? The SQL DateTime data type goes back Jauary 1, 1753 according to the documentation.
Yes, I have several records in our martial art masters table where the ancestral tree goes back several centuries.
>I think you're making this harder than it has to be <s>... If anything a lot of these things are easier because you don't have to write code to do it but can use the admin tools which are pretty easy to set up. Sure, you can have an Admin do that, but it's not necessary especially if you compare it to the level at which you'd do this with FoxPro data.
For that part, I guess I will surely find my way. The big problem right now is the package where I have issues with the identity key and the indexes that I need to preserve when the package finishes its run. To that, I will also have some work to do to add an integer field to accomodate for the date time values which go far in time.
>All of the Admin functionality can also be driven through code although it takes some scouring to find the right things to call.
My main goal for those types of procedures is a backup at midnight of the entire database. This is done by a robot.
>I say all of that because I tended to stick with FoxPro data for most of my Fox work as well although I started using SQL at some point. However, after having spend more time with SQL Server I find I miss many of the features in FoxPro.
It is not a perfect world.
>There's that and that's definitely an issue especially for Web applications. But keep in mind the time you are wasting right now and what that adds up to. And in the end the OleDb provider is just not a good choice for high end data access. It'll just cause you all sorts of grief down the road.
I'll do my best to get rid of that asap.
>It's a different story with Fox data driven through COM or VFP, but the OleDb driver is just a scary thing <g>...
You tell me. :) It is just that I have two clients right now waiting for their app to go in production. So far, the workaround to hide the errors to the user works. But, this is not a proper way to resolve the issue. At least, if Microsoft could release an updated version which would work under the .NET 2.0 at 100% of the time, that would help.
