1. I don't recall ever having seen a Word document that would fit in 255 bytes.
I just created a Word document containing a single letter ("a"), saved it to disk, and found a file size of 29KB. That was Word 2007 BTW.
2. The only type that is suited for storing binary data IMO is a "blob". MySQL offers blob, and some size variants thereof. Use those. I never used "binary".
3. Yes, saving and retrieving data to/from a database is tricky; as long as it doesn't work, it is hard to tell where the problem lies; it could be in the saving part, or in the retrieving part. And when you have several bugs at once (I'm sure you do!) fixing any one of them doesn't seem to help at all, until you get to the last one.
The good thing is, you have to solve it only once, as it would apply to any kind of data, as long as it fits a byte array model, it is all the same.
And the best thing is, millions of people have done this before, so the solution is bound to be available everywhere you look.
I need your helps now. I setup merge replication from Server A to server B and Server C and then i want to do the transaction replication from server A to another server D but i got a problem:
Publication cannot be subscribed toby Subscriber database because it contains one or more articles that have been subscribed toby the same Subscriber database at merge level.
Changed database context to (.Net SqlClient Data Provider)
If I setup only transaction replication it is working fine but when i setup Merge replication in Server A and after that i setup one more Transaction replication then i gave me the errors as mentioned.
Actually i have one server A do merge replication to clients. And now i want to do one more transaction replication in Server A to others but it occurred errors.
can we do Merge replication and transaction replication in the server A?
Basically with merge replication when a synchronization occurs, the final state of the rows is what is merged with the other side. So if I have a stock tracking table which each stock is updated thousands of times between synchronizations only the last value of the stock will be replicated.
With transactional replication with updateable subscribers the changes (the DML) will be replicated as transactions. So if a row in our stock table is updated 1,000 times there will be 1000 indivdual transactions will be replicated.
Now updateable subscribers is being deprecated and will likely not show up in SQL 11 and peer to peer is the desired upgrade path.
So if you need transactions replicated transactionally you would want updateable subscribers, if you want bi-directional synschronization between nodes which are frequently disconnected - merge replication is the way to go.
hello, in my application I have three tables: user, admin, operator each of these three can send a message to another the message can be a response to a message sent by the other or it may correspond to a command (because the user places orders to the admin and the admin can send a message on this order (Order approved, rejected, in process))
all of that concern an application of managment printing
my problem is to determinate how much I need to message tables (because there is a lot of messages (corresponding to order, response, simple message, which is sender and receiver....))
here is the image of my model http://postimage.org/image/fezebtifp/
Can you help me or give me examples of similar cases
I wrote a simple messaging application a few years ago and used something like the following:
Message table: MessageID -- the ID of message ParentID -- the ID of the immediate parent message ThreadID -- the ID of the first message in the thread SenderID -- the ID of the sender TimeSent -- timestamp Content... (whatever other columns you require)
Recipient table: MessageID -- the ID of the message RecipientID -- the ID of the recipient Read/Unread indicator
This allowed for multiple recipients for each message. I used GUIDs for IDs, but you could use INTs if you like.