For intranet development, our DBAs are asking web developers to use fixed domain NT ID accounts
instead of SQL accounts to connect to backend databases in all web applications. We are: Windows XP workstations in a 2003 Active Directory Topology.
I don’t think that this is a
good idea (I could say more:) but I have found very little to no information on this subject. So I ask you guys... What are your thoughts? Why or why not?
Hi,I'm in the process of designing a DB (typical management system DB; 2transaction tables and about 5 look-up ones )for one of the departmentsin our company. The user wants this DB and thusly the client (forms,reports..etc.) solely for his department. However, I do expect soonafter deployment that other users want similar DBs and clients,therefore, facing problem of integrating such DBs, if companymanagement wants to implement it as enterprise DB. My question (may beyou could also tell me about other groups specialized in these kind ofissues), how should I create such DB? Should I create extra look-uptable for departments and have each one with its own ID and link it tothe main transaction oneMTIA,Grawsha
View 3 Replies View RelatedI'm still a database newbie so I would like to solicit thoughts aboutthe smartest way to do something in sqlserver.My company has a web application that we customize for each client.We can do this because everything is database driven. We havedatabase tables that contain our HTML and database tables as well assome standard tables for each database. We have an in house app thatlets us tweak both of these things and creates a new web site anddatabase tailored to each project.Each of these sites has a table that stores a schedule are clientsuse.The records in this schedule table change when information in othercustom generated tables change.My company currently uses a legacy foxpro app to update the scheduletable.The foxpro app contacts sqlserver, reads a table with a list of tablesand scheduling information to check, checks each of those items andupdates the schedule table.I would like to lose the foxpro app.At first thought.........as a database newbie.......putting triggersin each of the tables to update the schedule when something changesseems the way to go.However, since we change a part of the schema ( we have an app thatgenerates the database tables unique to each client ) for each clientI would like a scheme that would not involve having to create adifferent trigger for each new table.I would also like something that updates in real time. Right now thefoxpro app is executed once a day.I was thinking of making a large stored procedure and putting anidentical call to that procedure in each table.Each table would have the same trigger in it that would get fired whenthe record was altered. It would call the stored procedure withrelevent arguments to update the schedule.Does this sound like a smart way to solve this problem or am I notthinking "database enough"?Any thoughts are welcome.I would like to build a better solutionSteve
View 1 Replies View RelatedI noticed that the current SLQCe driver does not offer support for the APM(Asynchronous Programming Model). Are there any plans to do this in the future? In light of the lack of APM functionality doe anyone have any ideas or thoughts on how async operations could be done, or if they are even needed in the context of applications that use SQL Ce
View 4 Replies View Related
Currently evaluating Red Gate SQL tools targetting SQL Server 2005 Express.
Specifically
- SQL Compare
- SQL Packager
- Dependency Tracker
This is the first tool of this kind that I've evaluated and must say I'm impressed. It looks like it will save me hours of writing scripts.
Any of you guys have any thoughts, recommendations, etc to share? Alternate tools?
Most appreciated in advance, thanks.
I was hoping to elicit some feedback on a trend I am seeing in the Portal market, and specifically with SharePoint development.
If you are not familiar with SharePoint, there is a data table abstraction within SharePoint called a "List". Lists are used for storing data (duh!). However, they are built using the SharePoint front end, and the data entered into all lists is stored in a few tables in the SharePoint content database.
What I am seeing happening is SharePoint gurus reccomending AGAINST storing your relational data within database tables, and within SharePoint lists instead. I am not sold on this approach, and it actually makes me think we are taking a step backwards with regards to persistent data storage and best practices.
- Lists cannot be natively related to one another, however they support "lookups"
- Anyone can create a list...and repeat the same data all over the enterprise.
- Lists are maintained in two tables within the SharePoint content database using meta-data patterns.
- Portals contain a multitude of sites. Users and portal admins can create lists all over the place, thus spreading related data over a wide swath of the enterprise.
Is it just me, or are SharePoint pundits absolutely CRAZY to be recommending persistent data storage using lists? I see nothing but problems arising from this approach.
I apologize beforehand if you have not worked with SharePoint and Lists, as this post may not make much sense to you. ;)
Thought I should post in the newbie forum for a while, instead. :-)
I have a couple of scripts that I've generated that drop a couple of system stored procedures and recreate them. I'm not sure why I did it in the first place, but I think it was that it wouldn't let me run an ALTER statement on them. Specifically, I'm now looking at sp_add_operator. I changed it to a 500 character email field instead of whatever it was (100, I think.)
/* Explanation: Why did I do that? SQL Mail is prohibited here, so I'm using CDO_Sysmail to email myself and the developers if a job fails. The list of people to email is determined by the owner of the database, who is also an operator in SQL. I get the list of emails from the email field of the operator properties. Hence, I need a bigger email field. Yes, I now know it would most likely be better to create an ADMIN database on each server for this kind of stuff. (Thanks to Tara for that blogged suggestion.) */
While I will probably go back to the default stored procedure, this got me to thinking: when would it be better to use an ALTER statement on a SProc rather than to do a DROP and CREATE?
Your thoughts, oh SQL gurus?
Folks, I have a quick question that I would very much appreciate somefeedback on. We are a not for profit charity organization that has decidedto develop a software in-house to manage our volunteers. We have SQL andthat makes the most sense from a database solution but we have some issuessurrounding the choice of the development language. Some have suggested100% java while others say Visual Basic. The head of our team has suggestedwe do it in Cold Fusion since this will be an internet based application andI guess I would very much like some feedback on that choice. We have about 5organizations that we will tie into this system with about 5000 userslogging in once per month.Any suggestions or comments would be greatly appreciated.CheersWade
View 4 Replies View RelatedI have a database with a dozen or so tables. No table constraints. Logic is all in stored procedures.
I have several Excel spreadsheets of data to import into the database, one speadsheet to a table. Each spreadsheet has additional data(columns) that each table has no interest in and should be ignored.
I would appreciate your thoughts on methods and best practices for loading this data to the database.
I am about to investigate SQL Server 2005 Express handling of XML. I am familiar with XML and XSL conversions and it seems to me that XSL conversion of Excel data to XML gives me a lot of flexibility prior to database import for shaping the data.
In short, importing data to the database from an XML source.
I am not famliar with SQL Server's XML capability and would appreciate thoughts on this while I look into it.
And of course alternate ways that I am overlooking.
Thanks
I just learned I can deploy and schedule jobs to run SSIS packages (via job/sqlagent) without the Integration Service (agent) itself actually running alongside (or on) the server. (Double-click on manifest, deploy IS package to server, create job/job step to run IS package, watch it run even when integration service is completely disabled)
Other than convenient viewing, configuring, and RMC running w/in SQL Server Mgmt Studio 2005, why then do I need the integration service running on a production box at all? When do I really need the IS service itself?
In our (finance) world only (a) an act of God or (b) a DBA can touch production databases/servers. Allowing anyone to connect to yet another service - in this case, an integration service - to meddle w/ a package would be a no no, so...
1) Could I trouble someone for a concrete, critical reason why the DBA should enable it on a production server. Speed? Caching? Peace of mind knowing everything is piled onto and neatly running on the server?
2) On a more minor note, if I'm deploying a package to be housed solely w/in MSDB, is there anyway to prevent the prompt of a file location during deployment, i.e. the creation of an empty directory that would otherwise hold package dependencies if I were running it as a file?
We'd like to deploy only to MSDB (I know all the pros/cons w/r/t saving dtsxs to files v. msdb) and keep deployments clean (read: all in one place). DR is via SAN-to-SAN replication with, among other things, msdb cleanly getting replicated. We would very much like to avoid having to worry about (more) file/directories sitting out on a server share to be replicated to DR (it seems the default is to allow deployments to directories on the SQL server instance itself..ugh) Any architectural insights on this would be appreciated.
Kind Regards,
Jim
I like the new gig a lot. Real busy, smart folks and I have been in high demand since 5 minutes after my butt hit the chair. I already have code in production.
Anyhow, we have a security situation on the sql servers I pointed out on my first day. So they want me to roll everything over to Windows Authentication and give the developers and report writers more restricted rights inside SQL Server. So they have NT Groups for different kinds of users and all of that jazz and I layed on the typical stuff about using NT groups vs individual accounts and ease of admin vs granularity of control. Well the boss came back and said he wants ease of admin and granularity of control over security. So, does anyone have any fresh thinking on turning my eitheror into an AND.
Hi,
I would appreciate any thoughts/ideas on the following use case for the distributed service broker application we plan to migrate from our existing proprietary tcp based message protocol using database tables for reliability.
There are two ssb services running in separate sql server instances, each on a different server machine. For simplicity, let us assume the ssb endpoint names are SSBA, SSBB. SSBB is the Initiator of the Dialog while SSBA is the Target. Now the requirement is that if the underlying network communication between the two ssb endpoints(SSBA and SSBB) is broken or if the critical service SSBB is down, then processing of any incoming message into SSBA's queue from a third service broker service (say SSBEXPR) running within a SqlExpress instance should be delayed until SSBB is alive and network communication between SSBA and SSBB is established. In our existing implementation (wherein SSBA, SSBB and SSBEXPR are windows services) we use a combination of TCP socket disconnects and Heartbeat messages between SSBA and SSBB to determine the health of network connection and that of the SSBB service.
Now my understanding of how the underlying network connection for a ssb dialog works is that if there is no activity on a dialog for a certain amount of time then the underlying network connection is closed. Is there a way to specify the amount of time to say infinite value or something and thus change this behavior? My other question is how can one query the underlying network connection (i.e. a row from sys.dm_broker_connections) associated with a particular conversation? If none of this is possible, then any other patterns/ideas/approach is welcome.
Thanks,
Hi,
I have a particularly difficult problem.
I have a SQL Server in an internal network and need to "replicate" to an identical server and database in a DMZ. The DMZ can only receive files sent by a custom component and no port(s) can be opened in the firewall or standard FTP used.
I also need to minimise traffic (i.e. sending whole tables is not an issue as some contain millions of rows), replicate approx once hourly and allow record locking only (as opposed to DB locking/exclsuive access or table locking).
Any thoughts / experiences greatly appreciated otherwise I'm looking at putting triggers on all the tables to monitor changes and generate SQL statements for execution against the DMZ server.