|
Hi,
Just thinking out loud, mind you, so for what it is worth:
The main question is, what sort of data would you need at each site, at the same time, that must be in absolute real time sync?
The different sites of your company have been established for a reason, and I suppose it is not because all the people just won't fit into a single building. So I am guessing each site has its own customers, or vendors, or specialized work crew, or warehouse, or something.
That means that although each site will be organized with the same application(s), each will still mostly be working with unique data.
In other words, each site will be creating its own orders, deliveries, invoices, or whatever other business objects, that are specifically related to that site.
So adding site identifiers to all business objects in your database, should allow you to have each site run its own server/database/copy of the application. You can keep a central database at a single location that is updated every night (or whenever), through synchronization, or even simpler, using xml files. This central database could send certain common master data to each site's own database in turn, every night, hour, 15 minutes, etc. depending on requirements.
Usually even things like warehouse stock levels needn't be more up to date then 5 minutes.
This approach shouldn't need any kind of drastic measures, and might even offer greater flexibility for future development.
Cheers,
Johan
My advice is free, and you may get what you paid for.
|
|
|
|
|
Thanks Johan,
There's some good points in there. Like you say, the company is divided by sites for a reason, and yes large parts of the data is specifically for an individual site. I'm going to take a look at each table and decide how up to date it needs to be with respect to each site.
Thanks for the suggestions.
Simon
|
|
|
|
|
Hi, I am working on application that have following basic requirement
• Data(name) will be stored in Marathi (non-English) language
• During search user will type english charachter from keybord and the result will be shown in Marathi.
Does anyone have idea how to achieve this? Is it possible to store marathi DB in access?
Thanks in advance.
|
|
|
|
|
Have some google mojo[^] that should get you the answer on storing unicode data in a database.
As for typing english and searching marathi data, you would need to translate one language to the other. You cannot search for an orange in the apple orchard.
|
|
|
|
|
mighty mojo you have.
|
|
|
|
|
Why would this simple select error like this: sql 2008?
SELECT field1
FROM ADDRESS
where field1 != 'NULL'
"Error Msg 8114, Level 16, State 5, Line 1
Error converting data type varchar to numeric."
The real goal is to get this select to work but there are two fields causing me problems. The two fields commented out are generating the same error as above....how would I insert a cast into the below query for fields 4 and 5?
use dbname
Select field1 + ' ' + ISNULL(field2,'')
+ ' ' + ISNULL(field3,'')
--+ ' ' + ISNULL(field4,'')
--+ ' ' + ISNULL(field5,'')
as column_new from table1
Error converting data type varchar to numeric."
Regards,
Hulicat
|
|
|
|
|
Hulicat wrote: SELECT field1
FROM ADDRESS
where field1 != 'NULL'
select field1 from ADDRESS where field1 is not null
Hulicat wrote: how would I insert a cast into the below query for fields 4 and 5?
select cast(field5 as varchar)
|
|
|
|
|
Thanks for the reply.
I am having an issue inserting the cast into this statement for feilds 4, 5:
use dbname
Select field1 + ' ' + ISNULL(field2,'')
+ ' ' + ISNULL(field3,'')
--+ ' ' + ISNULL(field4,'')
--+ ' ' + ISNULL(field5,'')
as column_new from table1
Regards,
Hulicat
|
|
|
|
|
Hulicat wrote: I am having an issue inserting the cast into this statement for feilds 4, 5:
I already gave you that answer...
Here it is in total since you seem to have not understood what I was talking about...
use dbname
Select field1 + ' ' + ISNULL(field2,'')
+ ' ' + ISNULL(field3,'')
+ ' ' + cast(field4 as varchar)
+ ' ' + cast(field5 as varchar)
as column_new from table1
|
|
|
|
|
When you use the cast as per damians suggestion you need to define the size of the varchar as int
ISNULL(Cast Field4 as varchar(20)),'')
|
|
|
|
|
Thanks that was jamming me up....got it thanks.
Regards,
Hulicat
|
|
|
|
|
Mycroft Holmes wrote: you need to define the size of the varchar as int
Interesting... not in SQL-2005 you don't!!
|
|
|
|
|
I am using 2008 and checked BOL before posting, I use Convert almost exclusively so I had to check, maybe the doco is out of date?
|
|
|
|
|
Maybe... I did it with SQL2005 before posting... don't have SQL2008 here...
|
|
|
|
|
I have a table containing production information that your users query frequently, They specifically use this
query most often (that is only use name to search in the where condition):
SELECT Name,Description,Vendor,Instock,Price FROM Products where Name='name'
Have a nonclustered index on this table on the Name column,but your users are complaining the query is still too
slow,what can you do to speed it up?
A、modify the index to include the Description,vendor,Instock, and price columns as nonkey columns.
B、Create a new nonclustered index on the Description,vendor,Instock, and price as nonkey columns.
C、Create a new clustered index on the Description,vendor,Instock, and price as nonkey columns.
D、You can't do anything to speed up this query.
Database is MS SQL SERVER.
Above four choices, which answer is right?please tell the reason.Thanks
|
|
|
|
|
Surely its obvious? Look at the select
SELECT Name,Description,Vendor,Instock,Price FROM Products where Name='name'
and the options:
B and C - why will creating these indices help? The search is on name only.
D - of course it can be speeded up
This leaves A. By including the other columns on the non-clustered index only the index will be read, therefore saving the read from the underlying table.
Hope this explains it, it really is a bit of a no-brainer question.
Bob
Ashfield Consultants Ltd
Proud to be a 2009 Code Project MVP
|
|
|
|
|
You know it would never occur to me to add these other fields into the index, I would leave it at D. The penalty of AED on that table/index would outweigh the benefits I would have thought.
Taking that advice to the next level and you get something like - every table that is in a select query should carry an index with every field in it!
|
|
|
|
|
Mycroft Holmes wrote: The penalty of AED on that table/index would outweigh the benefits I would have thought.
Based on the OP "I have a table containing production information that your users query frequently" implies to me that there are many more reads than writes, so once the index is created there is little overhead - however, based on the info given, that is not certain so you may be correct. In real life you make a judgement call based on your knowledge of the system.
Mycroft Holmes wrote: I would leave it at D
Not if you have a load of irate users on your back
In reality, the guy wanted to know the answer to an interview/exam question, and I would put my money on adding the other columns to the index being what they were looking for.
Bob
Ashfield Consultants Ltd
Proud to be a 2009 Code Project MVP
|
|
|
|
|
Ashfield wrote: In reality, the guy wanted to know the answer to an interview/exam question
It definitely feels like a theory question that has no basis in reality.
I would have trouble answering D as I know I don't know everything and I hate having to answer that to irate users, so I would be looking for the E option - more research required.
|
|
|
|
|
Thank you for your kindly help!
|
|
|
|
|
I would keep the index on Name and create another index on Name,Description,Vendor,Instock,Price
* This should solve any Bookmark problem - have you ran execution plan on your query? if this is a heavily 'write' table, you will pay the price when rebuilding indexes
|
|
|
|
|
Hi All,
I'm having some troubles working on my first stored proc using dynamic SQL and I've hit a brick wall and can't work out what I'm doing wrong. I have two tables that are always the same structure, however I wish to write a re-useable stored proc to copy records to a new table based on some value comparison. I have this in my stored proc at the moment:
ALTER PROCEDURE [dbo].[sp_CopyFileScorerChanges]
-- Add the parameters for the stored procedure here
@SourceTable NVARCHAR(100),
@TargetTable NVARCHAR(100)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @zSQL NVARCHAR(4000)
SET @zSQL = N'INSERT INTO ' + @SourceTable + '(
[FilePath],
[CurrentCategory],
[CurrentSubCategory],
[CurrentBpm],
[OldCategory],
[OldSubCategory],
[OldBpm]
)
SELECT
@FilePath,
@CurrentCategory,
@CurrentSubCategory,
@CurrentBpm,
@OldCategory,
@OldSubCategory,
@OldBpm
FROM ' + @TargetTable +
'WHERE CurrentCategory <> OldCategory'
EXEC( sp_ExecuteSQL @zSQL, N'@FilePath NVARCHAR(4000),
@CurrentCategory NVARCHAR(100),
@CurrentSubCategory NVARCHAR(100),
@CurrentBpm INT,
@OldCategory NVARCHAR(100),
@OldSubCategory NVARCHAR(100),
@OldBpm INT',
@FilePath,
@CurrentCategory,
@CurrentSubCategory,
@CurrentBpm,
@OldCategory,
@OldSubCategory,
@OldBpm
)
END
I'm currently getting a 'Incorrect syntax near 'sp_ExecuteSQL' - Expecting STRING, TEXT_LEX, VARIABLE or GLOBAL_VAR. I just want to call the stored proc with two table names, the source table and the target table.
Any help would be really appreciated.
Thanks,
|
|
|
|
|
You are trying to use a varable in dynamic sql, you cannot. Everywhere you are using @Var needs to be turned into a literal (like you do for target table).
When building dynamic sql I do a print @SQL and try and run the results, this will then give you more detailed results. It will also show that you are trying to insert @FilePath int a varchar without surrounding singles '
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Gotcha. All working now. Thank you!
|
|
|
|
|
Mycroft Holmes wrote: You are trying to use a varable in dynamic sql, you cannot. Everywhere you are using @Var needs to be turned into a literal (like you do for target table).
Wrong! sp_executesql will allow you to pass parameters into the SQL. He's using string concatenation for the table names because this is one place in SQL you cant use a variable.
|
|
|
|
|