I never post my problems but I have no time right now

I just released a beta and I am too busy with the testers right now.

New company. Brought into automate the back office and to advise on the design on their software. Lots of sloppiness here. Denormalized tables, inline SQL all of the usual crap I get paid to cleanup.

I have'nt gotten to this part of there process yet but they do some over night processing that can take up to 12 hours. (I can't wait to look at this code).

Data entry people get here at 6 am and their applications can't seem to connect to the SQL Server but the processing has stopped. They just hang and hang. The network guy comes in about 8 am and restarts the SQL Service Fonzi style and everything is fine. The DBA thinks it's a network issue which seems a tid bit ridiculous to me since restarting the service "fixes" it.

I suspecting it's a memory issue.

Any ideas on where to start.since you're one of the good guys i will ask you if you have a preference for what to rename the subject line of your question to, since the current subject is too nebulous|||on the other hand, it is fairly distinctive so i may just leave it

:) :) :)|||rename constipated SQL Server|||Log on to the SQL server, and see what is going on in Task Manager, first. You have probably already done that, but it does sound like a resource problem somewhere (memory, CPU, etc.). Can we hope this is SQL 2000? Or are you stuck with 6.5?

If there are no resource problems, and the operating system is running smoothly, you probably have some sort of open transaction hanging everyone up. The data entry application may have commandtimeout set to "0", which sounds about in line with what you describe of their code.|||My bet is on SQL object locking. I'd check sp_who (definitely not sp_who2 until I knew it was safe) before rebooting to see if a spid is blocking the rest of the known universe.

The lovely little nightly process might be camping on some resource that everybody needs to "wake up the daemons" in the morning. When you kick the ground out from under it (by restarting SQL), the locks are gone and life is lovely once again.

-PatP|||Yes it is SQL 2K.

Thanks guys. I will let you know the resolution. Of course I will have to come in at 6 am. No VPN here. Small shop.

Have a good weekend.|||How long does the "fix" take after it's restarted?

Are the files set to autogrow?

Is the log being blown out?

How do you know if the 12 hour batch windows actually completes.

Is there enough space left on the drives?

Are there any other services on the box that are in competition for the memory?

If there are, my first reccomendation would be to isolate|||Thanks. I will know more on Monday. I just have'nt had much time to think about this due to the revamp project from hell. I plan on being here early to gauge what is going on.

===========================================
How long does the "fix" take after it's restarted?

Immediate

Are the files set to autogrow?

Yes

Is the log being blown out?

Not sure I would have to check the log size before and after.

How do you know if the 12 hour batch windows actually completes.

They tell me so when I ask.

Is there enough space left on the drives?

Yes

Are there any other services on the box that are in competition for the memory?

This box is dedicated the SQL Server.

If there are, my first reccomendation would be to isolate|||My bet: uncommitted transactions in the nightly process.

I need some advice before starting VB/SQL Project

I am just in the process of learning VB.NET so that I can upsize an access database that I developed for my company.

I need advise on two subjects:
First, I am going to be starting a new VB.NET / SQL project using MSDE installed on my development computer. What do I need to do to allow me to easily deploy the program on several workstations and a dedicated server once development is finished?

Second, I would like to have a transitional period where both the VBA in the current MDB and the new VB.NET project access the same data. The one solution that I came up with was creating queries on the SQL server that pointed to the MDB, then once I am comfortable with the VB.NET end of things I would transfer the data it's self to the SQL server and change the queries to point to the new data location... However I have no idea weather or not this will work or if it is even close to being a good idea.

Any advice would be greatly appreciated.I wouldn't waste my time on developing in Access and then moving to SQL Server. Just start with the latter!|||Michael Kaiser

Brett Smith

Geez I thought I was unique...

Anyway, take rdjabarov's advice...

You can easily set up an Access mdb and link the sql server tables to it...

Don't bother with Jet...or don't you have sql server installed yet?

Or is it an existing application already?

How big is the database (or how big will it be?)

Also, you don't mention anything about stored procedures...

Do you plan on using them...it would be a big plus, especially for you're design implementation...|||Absolutely. Creating queries in SQL Server that point to data in a transitional Access database is going to cause you more trouble than just building the tables in SQL Server to begin with.

Hey, I like Access a lot, but there is really no point in using it in your development if it is not going to be part of your final solution.

If your data is already in Access, then it is worth trying the Upsizing wizard. I've used it once or twice and I seem to recall that it did a decent job. If you need a transitional application, then move your existing forms and code into a Microsoft Access Data Project that is tied directly to your SQL server database.|||Unfortunately I am already up to my eyeballs in Access
This is at the moment the primary issue tracking system for the small consulting firm that I work for. Hundreds of contacts, thousands of related records... and it has only been in use for about 6 months.

What I need to do is develop the project in vb and slowly transfer functionality over as modules get debugged.

To answer the other question about stored procedures, I am definitely going to be using them.|||I'm a little confused (and that's on a good day)...

Is the data centraly located, or does each client have their own copy of the data?|||Then again, I think you would be best off if you transfered the data to Microsoft SQL server and converted your Access database into an Access Data Project while you transition to your final solution.|||The data is centrally located in a mdb that only contains tables and each client has their own MDB file which has all the forms reports and VBA and links to the tables on the main database

I won't even begin to try to explain how this configuration came about, just keep in mind that decisions like that came about via committee and I (the actual developer) was not invited.|||Well, that's not a bad configuration for a distributed Microsoft Acces solution, but it does make your upsizing more difficult.

You could still develop an Access Data Project file and distribute it to your users. If you import your forms and modules it should look identical to them. Somewhere, you are going to have to bite the administrative bullet and come up with the transition strategy that best suits your business.|||I guess at this point I am going to look into an ADP, what I was hoping to avoid was spending any more time in access when it's not in the final plan. I know that the upsize wizard will not work for most of my forms and two of my tables, but I may just have to do it and get it over with|||Just another thought, would it make senct to just migrate the data to SQL and then change the links in the client MDB files to point to the SQL tables via an ODBC connection rather than actually transfer everything over to an ADP?|||I would...

a data source is a data source...

Only downside depends on the complexity of the forms/reports...

could be a lot slower depending on the # of connections opened by a form or report..|||Sure. Just make sure your security is good. Also, chances are good that you performance will be significantly slower than if you used an ADP interface.|||This is looking like my best option.

The last question on that front would be does anyone know if I like an Access MDB to SQL via ODBC can I use a SQL View for the source and meke it appear to Access to be a linked table?

I would only want to do this for two of the tables, because I would like to make some changes to the table field names.|||Yeah...check it out...they'll appear just like tables...

Just make sure that the view is updatable...otherwise it'll be a problem...|||I would get away from linked objects all together and replace them with pass-through queries to guarantee a more-or-less reasonable performance (I still don't understand why you would want to stick to Access to be your middle man.)

And to answer your question, - yes you can set a view as a source for a linked object.|||I think I am on my way!

I am sure that I will be back soon with other questions, but this should at least allow me to get my data onto SQL wile making very minor changes to the current Access database.